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Foreword 

This Technical Specification has been produced by the 3"* Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

IP Multimedia (IM) Core Network (CN) subsystem Service Continuity (SC) provides the capability of continuing 
ongoing communication sessions with multiple media across different access networks or across different user 
equipments (UEs) under the control of the same subscriber. 

NOTE: When the communication session is transferred across different UEs, the session can be a collaborative 
session with controller and controllee UEs. In this version of the document, there can only be one 
controller UE but several controllee UEs in the collaborative session. 

The present document provides the protocol details for enabling IMS SC based on the Session Initiation protocol (SIP) 
and the Session Description Protocol (SDP) and the protocols of the 3GPP Circuit-Switched (CS) domain (e.g. CAP, 
MAP, ISUP, BICC and the NAS call control protocol for the CS access). 

The present document is apphcable to User Equipment (UEs) and Application Servers (AS) providing IMS Service 
Continuity capabilities. 



2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 

non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 



[I] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] 3GPP TS 24.229: "IP multimedia call control protocol based on Session Initiation Protocol (SIP) 

and Session Description Protocol (SDP); Stage 3". 

[3] 3GPP TS 24.228 Release 5: "Signalling flows for the IP multimedia call control based on Session 

Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3". 

[4] 3GPP TS 24.292: "IP Multimedia (IM) Core Network (CN) subsystem CentraUzed Services (ICS); 

Stage 3". 

[5] 3GPP TS 24.216: "Communication continuity managed object". 

[6] 3GPP TS 29.328: "IP Multimedia Subsystem (IMS) Sh interface; SignalUng flows and message 

contents". 

[7] 3GPP TS 29.329: "Sh interface based on the Diameter protocol; Protocol details". 

[8] 3GPP TS 24.008: "Mobile radio interface layer 3 specification; Core Network protocols; Stage 3". 

[9] 3GPP TS 23.237: "IP Multimedia subsystem (IMS) Service Continuity; Stage 2" . 

[10] IETF RFC 3891 : "The Session Initiation Protocol (SIP) "Replaces" Header" . 

[II] IETF RFC 4538: "Request Authorization through Dialog Identification in the Session Initiation 
Protocol (SIP)". 

[12] 3GPP TS 23.003: "Numbering, addressing and identification". 

[13] IETF RFC 3515: "The Session Initiation Protocol (SIP) Refer Method". 
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[14] 3GPP TS 23.167: "IP Multimedia Subsystem (IMS) emergency sessions". 

[15] 3GPP TS 23.228: "IP Multimedia Subsystem (IMS); Stage 2". 

[16] IETF RFC 5012 (January 2008): "Requirements for Emergency Context Resolution with Internet 

Technologies". 

[17] IETF RFC 5031 (January 2008): "A Uniform Resource Name (URN) for Services". 

[18] 3GPP TS 29.292: "Interworking between the IP Multimedia (IM) Core Network (CN) subsystem 

and MSC Server for IMS CentraUzed Services (ICS)". 

[19] IETF RFC 3261: "SIP: Session Initiation Protocol". 

[20] IETF RFC 4488: "Suppression of Session Initiation Protocol (SIP) REFER Method Imphcit 

Subscription". 

[21] IETF RFC 4825: "XML Media Types". 

[22] draft-ietf-sip-outbound-20 (June 9, 2009): "Managing Client Initiated Connections in the Session 

Initiation Protocol (SIP)". 

Editor's note: The above document cannot be formally referenced until it is published as an RFC. 

[23] 3GPP TS 24.286: "IP Multimedia (IM) Core Network (CN) subsystem Centralised Services (ICS); 

Management Object (MO)". 

3 Definitions and abbreviations 
3.1 Definitions 



For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following 
apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 3GPP 
3GPP TR 21.905 [1]. 

Dynamic STI: An STI dynamically assigned by the SCC AS, representing the SIP dialog identifier (Call-ID header 
field and the values of tags in To and From header fields) and used for session transfer request when Gm service control 
is available. 

Static STI: An STI configured in the SC UE either as a SIP URI or as an E.164 number in tel URI or SIP URI 
representation of tel URI. The static STI is used for CS-PS transfer when dynamic STI is unavailable. 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.292 [4] apply: 

Correlation MSISDN 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.237 [9] apply: 

Access Leg 

Remote Leg 

Target Access Leg 

Source Access Leg 

Session Transfer Identifier (STI) 

Session Transfer Number (STN) 

Session Transfer Number for SR-VCC (STN-SR) 

Collaborative session 

ControUee UE 

ControUer UE 

Inter-UE transfer 

Emergency Session Transfer Number for SR VCC(E-STN-SR) 
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For the purposes of the present document, the following terms and definitions given in 3GPP TS 24.292 [4] apply: 

CS call 
CS media 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.003 [12] apply: 

IP Multimedia Routing Number (IMRN) 
For the purposes of the present document, the following terms and definitions given in IETF RFC 5012 [16] apply: 

Emergency service URN 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
3GPPTR 21.905 [1]. 



EATF 


Emergency Access Transfer Function 


E-STN-SR 


Emergency Call Session Transfer Number - Single Radio 


E-SR-VCC 


Emergency Single Radio Voice Call Continuity 


IMRN 


IP Multimedia Routing Number 


SC 


Service Continuity 


sec 


Service CentraUzation and Continuity 


SR-VCC 


Single Radio VCC 


STI 


Session Transfer Identifier 


STN 


Session Transfer Number 


STN-SR 


Session Transfer Number - Single Radio 



4 Overview of IP IVIultimedia (IIVI) Core Network (CN) 
subsystem Service Continuity 

4.1 General 

In general, IMS Service Continuity can be divided into two concepts: 

1. providing the capability of transferring ongoing communication sessions with multiple media across different 
access networks. The main need for such continuity arises because user equipments (UEs) with multimedia 
capabilities can move across a multiplicity of different access networks; and 

2. providing the capability of transferring the connmunication sesions with multiple media across different UEs. 
The following procedures are provided within this document: 

- procedures for registration in IM CN subsystem are specified in clause 6; 

- procedures for call origination are specified in clause 7; 

- procedures for call termination are specified in clause 8; 
procedures for PS-CS access transferare specified in clause 9; 
procedures for PS-PS access transferare specified in clause 10; 

- procedures for PS-PS access transferin conjunction with PS-CS access transferare specified in clause 11; 

- procedures for PS-CS access transferfor Single Radio are specified in clause 12; 

- procedures for media adding/deleting for access transfer are specified in clause 13; 
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- procedures for UE discovery for inter-UE transfer are specified in clause 14; 

- procedures for inter-UE transfer without establishment of collaborative session are specified in clause 15; 

- procedures for collaborative session estabUshment for inter-UE transfer are specified in clause 16; 

- procedures for media transfer within collaborative session for inter-UE transfer are specified in clause 17; 

- procedures for release of collaborative session for inter-UE transfer in clause 18; 

- procedure for media adding/deleting within collaborative session for inter-UE transfer are specified in 
clause 19; and 

- procedures for service continuity and MMTEL interactions are specified in clause 20. 

For a UE or an AS not supporting ICS procedures, PS-CS service continuity is only possible when the UE is active in a 
single full-duplex speech or speech/video session i.e. support of access transfer or inter-UE transfer with more than one 
session or with non voice media is not provided. 

4.2 Underlying network capabilities 

SC assumes the use of a number of imderlying network capabiUties: 

1) provision by the home network operator of SCC AS on the IM CN subsystem, as specified in 
3GPPTS 24.229 [2]; 

2) if ICS is used, the network capabiUties as specified in 3GPP TS 24.292 [4]; 

4.3 URI and address assignments 

In order to support SC to a subscriber, the following URI and address assignments are assumed: 

a) in this version of the document, the SC UE for access transfer will be configured with both a static STl and a 
static STN. The static STI is used by the SC UE to perform CS to PS access transfer when no dynamically 
assigned STI is provided to the UE over the CS domain (e.g. when the SC UE does not support ICS capabiUties). 
The static STN is used by the SC UE to perform PS to CS access transfer when no service control signaUing path 
as specified in 3GPP TS 24.292 [4] is available. 

b) the SC UE will be configured to be reachable in both the IM CN subsystem and the CS domain by one or more 
public telecommunication numbers which should be correlated between the CS domain and IM CN subsystem. 
Either: 

- this public teleconamunication number can be the DN (e.g. MSISDN) used in the CS domain and (in 
international form) comprise part of the implicit registration set associated with that SC UE in the IM CN 

subsystem; or 

- the SCC AS can be configured to provide a functional relationship between separate numbers providing each 
of these identities in the CS domain and the IM CN subsystem, respectively. 



5 Functional entities 

5.1 Introduction 

This clause associates the functional entities with the SC roles described in the stage 2 architecture document (see 
3GPPTS 23.237 [9]). 

5.2 User Equipment (UE) 

UE can be compliant with: 
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- both the access transfer and the inter-UE transfer; 

- the access transfer; or 

- the inter-UE transfer 
in this document. 

To be compliant with access transfer in this document, a UE shall implement the role of an SC UE according to 
subclause 6.2, subclause 7.2, subclause 8.2, subclause 9.2, subclause 10.2, subclause 11.2, subclause 12.2 and 
subclause 13.2. 

To be compliant with inter-UE transfer in this document, an SC UE shall implement the role of an SC UE according to 
subclause 14.2, subclause 15.2, subclause 16.2, subclause 17.2, subclause 18.2 and subclause 19.2. 

NOTE: In the inter-UE transfer, a session can be collaborative session where there are one controller UE and 

severeal controUee UEs. The controUee UE can be a legacy UE and does not have be compUant with the 
above subclauses. 

5.3 Application Server (AS) 

AS can be compliant with: 

- both the access transfer and the inter-UE transfer; 

- the access transfer; or 

- the inter-UE transfer 
in this document. 

To be compliant with access transfer in this document, an AS shall implement the role of an SCC AS according to 
subclause 6.3, subclause 7.3, subclause 8.3, subclause 9.3, subclause 10.3, subclause 11.3, subclause 12.3 and 
subclause 13.3. 

To be compliant with inter-UE transfer in this document, an AS shall implement the role of an SCC AS according to 
subclause 14.3, subclause 15.3, subclause 16.3, subclause 17.3, subclause 18.3 and subclause 19.3. 



6 Roles for registration in the IM CN subsystem for 
service continuity 

6.1 Introduction 

A 3rd-party registration shall be performed via the ISC interface for the SCC AS. 

6.2 SC UE 

Prior to performing IMS registration the SC UE if it supports ICS capabilities shall check that IMS service continuity 
using ICS is enabled. An indication that IMS service continuity using ICS is enabled can be found in the ICS MO 
ICS_Capabilities_Enabled leaf node (see 3GPP TS 24.286 [23]). 

The SC UE shall follow the procedures specified in 3GPP TS 24.229 [2] for registration of the UE in the IM CN 
subsystem. 

If IMS service continuity using ICS is enabled then prior to making use of IMS ICS procedures, the SC UE shall follow 
the procedures specified in 3GPP TS 24.292 [4] for registration of the ICS UE in the IM CN subsystem. 
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6.3 sec AS 

The sec AS can obtain registration state information that it needs to implement SCC specific requirements from: 

a) any received third-party REGISTER request (e.g. including information contained in the body of the third-party 
REGISTER request) as specified in 3GPP TS 24.229 [2]; 

b) any received reg event package as specified in 3GPP TS 24.229 [2]; or 

c) the Sh interface as specified in 3GPP TS 29.328 [6] and 3GPP TS 29.329 [7]. 

NOTE: Obtaining registration state information from HSS using Sh interface does not allow the SCC AS to know 
the capabiUties supported by the user registered UE(s), including the used IP-CAN(s). 

When the SCC AS receives a REGISTER request and obtains the registration state information including an Correlation 
MSISDN using one of the above procedures, the SCC AS shall determine if the REGISTER request is associated with 
ongoing CS call by matching the Correlation MSISDN against the: 

a) tel URI in the P-Asserted-Identity header field or associated with the received IMRN when the SIP INVITE 
request was due to static STN, where the SIP INVITE request was stored according to subclause 7.3.1; or 

b) tel URI in the Request-URl when the SIP INVITE request was due to processing unregistered filter criteria, 
where the SIP INVITE request was stored according to subclause 7.3.1. 

If the REGISTER request is associated with an ongoing call the contents of the Contact header field in the REGISTER 
request shall be bound to the ongoing CS call session identifier. 

6.4 MSG server 

If MSC server supports the MSC server assisted mid-call feature, the MSC server shall behave as an MSC server 
enhanced for ICS as specified in 3GPP TS 29.292 [18] and 3GPP TS 24.292 [4] with following additions: 

- include the media feature tag g.3gpp.mid-call as described in annex C in the Contact header field of the SIP 
REGISTER request; 



7 Roles for call origination for service continuity 

7.1 Introduction 

This clause specifies the procedures for call origination, both where the SC UE is generating calls in the CS domain and 
where the SC UE is generating calls using the IM CN subsystem. Procedures are specified for the SC UE, the SCC AS 
and the EATF. 

7.2 SC UE 

If IMS service continuity using ICS is enabled then the SC UE shall support origination of multimedia sessions in the 
IM CN subsystem as specified in 3GPP TS 24.229 [2]. If the SC UE supports the MSC server assisted mid-call feature, 
the SC UE shall include the media feature tag as described in annex C in the Contact header field of the SIP INVITE 

request. 

The SC UE shall support origination of calls in the CS domain as specified in 3GPP TS 24.008 [8]. 

The procedures for call origination where the SC UE is initiating calls using CS media are identical to that for ICS UE 
specified in 3GPP TS 24.292 [4]. 

When originating an IMS emergency call as specified in 3GPP TS 24.229 [2] and if the SC UE has an IMEI, then the 
SC UE shall include the instance-id feature tag as specified in [22] with value based on the IMEI as defined in 
3GPP TS 23.003 [12] in the Contact header field of the SIP INVITE request. 
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7.3 sec AS 

7.3.1 Distinction of requests sent to tlie SCC AS 

The SCC AS needs to distinguish between the following initial SIP ESTVITE requests to provide specific fimctionahty 
relating to call origination: 

SIP INVITE requests routed to the SCC AS over the ISC interface as a result of processing filter criteria at the S- 
CSCF according to the origination procedures as specified in 3GPP TS 24.229 [2J, and therefore distinguished 
by the URI relating to this particular filter criteria appearing in the topmost entry in the Route header. In the 
procedures below, such requests are known as "SIP INVITE requests due to originating filter criteria". It is 
assumed that the SCC AS is the first AS that the S-CSCF forwards the request to after receiving the request from 
theUE. 

The SCC AS shall store the SIP INVITE requests due to static STN (as defined in subclause 9.3.1) and the SIP INVITE 
requests due to originating filter criteria, at least until their sessions are terminated. 

Other SIP initial requests for a dialog, and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [8]. 

7.3.2 Call origination procedures at the SCC AS 

When the SCC AS receives a SIP INVITE request due to originating filter criteria, the SCC AS shall follow the SCC 
AS roles for call origination procedures specified in 3GPP TS 24.292 [4]. 

If 

1 . the SCC AS supports the MSC Server assisted mid-call feature according to operator pohcy; 

2. the media featme-tag g.3gpp.mid-call as described in annex C is included in the Contact header field of the SIP 
INVITE request due to originating filter criteria; and 

3. the SCC AS is aware that all MSC Servers in the network where the UE is registered which can be involved in 
the SRVCC procedures support the MSC Server assisted mid-call feature; 

NOTE: SCC AS can identify the network where the UE is registered based on the P-Visited-Network-Id header 
field and the P- Access-Network-Info header field of the SIP REGISTER request. 

then the SCC AS shall include the media feature-tag g.3gpp. mid-call as described in annex C in the Contact header field 
of the SIP 2xx response to the SIP INVITE request due to originating filter criteria. 

If the SCC AS supports the MSC Server assisted mid-call feature according to operator policy, the SCC AS shall 
remove the media feature-tag g.3gpp.mid-call as described in annex C fiom the SIP INVITE request due to originating 
filter criteria before forwarding the SIP INVITE request towards the remote UE. 

7.4 EATF 

7.4.1 Distinction of requests sent to the EATF 

The EATF needs to distinguish between the following initial SIP INVITE requests to provide specific functionaUty 
relating to call origination: 

- SIP INVITE request including a request URI that contains an emergency service URN, i.e. a service URN with a 
top-level service type of "sos" as specified in IETF RFC 5031 [17]. In the procedures below, such requests are 
known as "SIP INVITE requests due to emergency service URN". 

Other SIP initial requests for a dialog, and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [8]. 
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7.4.2 Call origination procedures at the EATF 

When the EATF receives a SIP INVITE requests due to emergency service URN, the EATF shall store the SIP INVITE 
request until the session is terminated, anchor the session and act as a routeing B2BUA as described in 
3GPP TS 24.229 [2]. 

Editor's note: it is FFS whether EATF needs to fulfill all the functionality of the routeing B2BUA or whether a new 
role needs to be defined for EATF in 24.229 



8 Roles for call termination for service continuity 

8.1 Introduction 

This clause specifies the procedures for call termination, both where the SC UE is receiving calls in the CS domain and 
where the SC UE is receiving calls using the IM CN subsystem. Procedures are specified for the SC UE and the 
sec AS. 

8.2 SC UE 

The SC UE shall support termination of multimedia sessions in the IM CN subsystem as specified in 
3GPP TS 24.229 [2]and in 3GPP TS 24.292 [4]. If the SC UE supports the MSC server assisted mid-call feature, and 
the receiving SIP INVITE request includes media feature tag as described in annex C in the Contact header field, the SC 
UE shall include the media feature tag as described in annex C in the Contact header field of the SIP 2xx response to the 
SIP INVITE request. 

The SC UE shall support termination of calls in the CS domain as specified in 3GPP TS 24.008 [8]. 

The procedures for call termination where the SC UE is receiving calls using CS media are identical to that for ICS UE 
roles for call termination procedures which are specified in 3GPP TS 24.292 [4]. 

8.3 sec AS 

8.3.1 Distinction of requests sent to the SCO AS 

The sec AS needs to distinguish between the following initial SIP INVITE requests to provide specific functionality 
relating to call termination: 

SIP INVITE requests routed to the SCC AS over the ISC interface as a result of processing filter criteria at the S- 
CSCF according to the termination procedures as specified in 3GPP TS 24.229 [2], and therefore distinguished 
by the URI relating to this particular filter criteria appearing in the topmost entry in the Route header. In the 
procedures below, such requests are known as "SIP INVITE requests due to terminating filter criteria". It is 
assumed that the SCC AS is the last AS that the S-CSCF forwards the request to. 

Other SIP initial requests for a dialog, and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [2]. 

8.3.2 Call termination procedures in the SCC AS 

When the SCC AS receives a SIP INVITE request due to terminating filter criteria, the SCC AS shall follow the SCC 
AS roles for call termination procedures specified in 3GPP TS 24.292 [4]. 

If 

1 . the SCC AS supports the MSC Server assisted mid-call feature according to operator policy; and 

2. the SCC AS is aware that all MSC Servers in the network where the UE is registered which can be involved in 
the SRVCC procedures support the MSC Server assisted mid-call feature; 
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then the SCC AS shall include the media feature-tag g.3gpp. mid-call as described in annex C in the Contact header field 
of the SIP INVITE request due to terminating filter criteria. 

If the SCC AS supports the MSC Server assisted mid-call feature according to operator policy, the SCC AS shall 
remove the media feature-tag g.3gpp. mid-call as described in annex C from the SIP 2xx response to the SIP INVITE 
request due to terminating filter criteria before forwarding the SIP 2xx response towards the remote UE. 



9 Roles for PS-CS access transfer 

9.1 Introduction 

For a UE or an AS not supporting ICS procedures, PS-CS access transfer is only possible when the UE is active in a 
single full-duplex speech or speech/video session i.e. support of session transfer with more than one sessions or with 
non voice media is not provided. 

9.2 SC UE 

9.2.1 SC UE procedures for PS to CS access transfer 

The SC UE may be engaged in one or more ongoing IMS sessions at the time of initiating access transfer. By an 
ongoing IMS session, it is meant a session for which the 2xx response for the initial SIP INVITE request to establish 
this session has been sent or received. 

If IMS service continuity using ICS is enabled then if the SC UE is using Gm, then for each session to be transferred 
and starting with the active session, the SC UE shall send a SIP INVITE request to the SCC AS according to the ICS 
UE using Gm procedures for call origination as specified in 3GPP TS 24.292 [4]. The SC UE shall populate the SIP 
INVITE request as specified for PS-PS access transferwith full media transfer in subclause 10.2.1. 

If the SC UE is not using ICS capabilities and if the SC UE does not apply the MSC Server assisted mid-call feature as 
specified in subclause 9.2.1 A, then access transfer is only possible when the UE is active in a single full-duplex speech 
session. If multiple full-duplex speech sessions exist, the SC UE shall first initiate the release of all the ongoing full- 
duplex speech sessions except the session with active full-duplex speech component that was most recently made active 
and then the SC UE shall transfer the remaining ongoing active full-duplex speech session. 

When transferring the session(s) not using ICS capabilities, the SC UE shall send, to the SCC AS, a message (e.g. 
CC_SETUP as specified in 3GPP TS 24.008 [8]) to set up a call over the CS domain. When sending CC_SETUP, the 
SC UE shall populate the CC_SETUP as follows: 

1) the called party BCD number information element set to the static STN. 

If the SC UE receives a release message to the CC SETUP message sent, then PS-CS acccess transfer has not completed 
successfully and the call will continue in the Source Access Leg. 

9.2.1 A SC UE procedures for PS to CS access transfer with IVISC server 
assisted mid-call feature 

Editor's note: access transfer when only the held sessions are established is EES 

Editor's note: it is FFS how to ensure that the UE and the MSC Server would use the same transaction identifers for 
the conferencing sessions 

The SC UE shall apply the MSC Server assisted mid-call feature when transferring the session not using ICS 
capabilities if 

1. the SC UE supports the MSC Server assisted mid-call feature; and 
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2. there is at least one ongoing active full-duplex speech session and the Contact header field provided by remote 
UE at the establishment of the ongoing active full-duplex speech session which has been most recently made 
active includes the media feature-tag g.Sgpp.mid-call as described in annex C. 

When the SC UE applies the MSG Server assisted mid-call feature, in addition to the procedures described in 
subclause 9.2.1, the SC UE shall, before sending a message to set up a call over the CS domain: 

1. if there are two or more ongoing active full-duplex speech sessions: 

A. initiate the release of all the ongoing full-duplex speech sessions except two that were most recently made 
active; 

B. initiate the session modification of the ongoing full-duplex speech session that was made active less recently 
and offer the full-duplex speech component as inactive; and 

C. transfer two remaining ongoing full-duplex speech sessions; 

NOTE: When active and inactive ongoing full-duplex speech sessions exist, one CC_SETUP message transfers 
both sessions. 

2. if there is one ongoing active full-duplex speech session and one or more ongoing inactive full-duplex speech 
session, 

A. initiate the release of all the ongoing inactive full-duplex speech sessions except the one which became 
inactive most recently; and 

B. transfer two remaining ongoing full-duplex speech sessions; and 

3. if there is one ongoing active full-duplex speech session and no ongoing inactive full-duplex speech session, 
transfer the ongoing full-duplex speech session. 

The SC UE shall associate the additional transferred session with CS call with transaction identifier calculated as in the 
table 9.2.1A-1 and TI flag value as in mobile originated call. 

Table 9.2.1 A-1: held session transaction identifier calculation formula 



<transaction identifier of the additional transferred session> = (1 + <transaction identifier 
of the CS call established by the SETtJP message>) modulo 7 



9.2.1 B SC UE procedures for PS to CS access transfer with MSC server 
assisted mid-call feature for speech and video session 

When PS to CS access transfer occurs, with a speech and video session and another speech session using PS media in 
the SC UE, the SC UE applies the MSC Server assisted mid-call feature according to the procedures described in 
subclause 9.2.1 A with the following additions: 

- if the SC UE supports SCUDIF feature, and the speech and video session is active and speech session is inactive 
the SC UE shall transfer the active speech and video session as specified in subclause 9.2.1, and indicate the 
support of SCUDIF in the SETUP message as specified in 3GPP TS 24.008 [8], with multimedia bearer 
capability preferred for the current active session; and 

- if the SC UE supports SCUDIF feature, and the speech and video session is inactive and speech session is active, 
the SC UE shall transfer the speech session as specified in subclause 9.2.1, and indicate the support of SCUDIF 
in the SETUP message as specified in 3GPP TS 24.008 [8], with speech bearer capability preferred for the 

current active session. 

NOTE: After successful transfer of the speech and video session and another speech session from PS to CS, the 

UE can switch between the two sessions by holding/releasing the active session and resuming the inactive 
session as specified in 3GPP TS 24.008 [8], with the addition that the UE can initiate the in-call 
modification or Redial procedures as specified in 3GPP TS 24.008 [8] to change the shared CS bearer of 
the two sessions from speech to multimedia, or vice versa. 
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9.2.2 SC UE procedures for CS to PS access transfer 

The SC UE may be engaged in one or more ongoing sessions before performing access transfer. By an ongoing session, 
it is meant a CS call for which the CS call setup procedure is complete, e.g. CC CONNECT message has been sent or 
received as described in 3GPP TS 24.008 [8] or a call for which the 2xx response for the initial SIP INVITE request to 
establish this session has been sent or received. 

If not already IMS registered, the SC UE shall follow the procedures specified in subclause 6.2 to perform IMS 
registration over the Target Access Leg before performing CS to PS access transfer. 

If IMS service continuity using ICS is enabled then if the original sessions are established using ICS capabilities, then 
for each session to be transferred and starting with the active session, the SC UE shall send a SIP INVITE request to the 
sec AS in accordance with the UE procedures specified in 3GPP TS 24.229 [2]. The SC UE shall populate the SIP 
INVITE request as specified for PS-PS access transfer with full media transfer in subclause 10.2.1. 

If the original sessions are not established using ICS capabilities and the SC UE does not support the MSC Server 
assisted mid-call feature as described in subclause 9.2.3, then access transfer is only possible when the SC UE is active 
in a single full-duplex speech session. If multiple full-duplex speech sessions exist, the SC UE shall first initiate the 
release of all the ongoing sessions that are currently not active and then the SC UE shall transfer the remaining ongoing 
active full-duplex speech session. 

When transferring the session(s) not using ICS capabilities, the SC UE shall send a SIP INVITE request to the SCC AS 
in accordance with the UE procedures specified in 3GPP TS 24.229 [2] . The SC UE shall populate the SIP INVITE 
request as follows: 

1) the Request-URI set to the static STI; and 

2) include in the Contact header field a public GRUU or temporary GRUU as specified in 3GPP TS 24.229 [2J, if a 
GRUU was received at registration. 

If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request, then session transfer has not occurred 
and the call will continue in the CS domain. 

When the SC UE receives a CS call release message, e.g. CC DISCONNECT message as specified in 

3GPP TS 24.008 [8], from the network, the SC UE shall comply with network initiated call release procedures to 

release the CS bearer. 

9.2.3 SC UE procedures for CS to PS access transfer with MSC server 
assisted mid-call feature 

When the SC UE supports the MSC Server assisted mid-call feature, the SC UE shall populate the SIP INVITE request 
for transferring the session not using ICS capabilities as follows in addition to the procedures described in 
subclause 9.2.2: 

1. the Supported header field containing the option-tag "norefersub" specified in IETF RFC 4488 [20]; 

2. the Accept header field containing the MIME type as specified in annex D.1.3; and 

3. include in the Contact header field the media feature-tag g.3gpp.mid-call as described in annex C. 

NOTE 1 : If the original sessions are not established using ICS capabilities and the SCC AS and the SC UE support 
the MSC Server assisted mid-call feature, up to one active and up to one inactive full-duplex speech 
session can be transferred. 

Upon receiving a SIP REFER request within the SIP session established by the SIP INVITE request for transferring the 
session not using ICS capabilities: 

1. with the Refer-Sub header field containing "false" value; 

2. with the Supported header field containing "norefersub" value; 

3 . with the Target-Dialog URI header field in the URI of the Refer-To header field; 
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4. where the remote UE included the feature -tag g.3gpp. mid-call as specified in annex C in the Contact header field 
of the SIP 2xx response to the SIP INVITE request; and 

5. containing a MIME body of MIME type specified in the annex D. 1 .3; 

and if the SC UE supports the MSC Server assisted mid-call feature, then the SC UE shall: 

1. handle the SIP REFER request as specified in 3GPP TS 24.229 [2], IETF RFC 3515 [13] and 
IETF RFC 4488 [20]; and 

2. send a SIP INVITE request for an additional inactive session in accordance with the procedures specified in 
3GPP TS 24.229 [2] and IETF RFC 3515 [13]. The SC UE shall populate the SIP INVITE request as follows: 

A. header fields which were included as URI header fields in the URJ in the Refer-To header field of the 
received SIP REFER request as specified in IETF RFC 3261 [19] except the "body" URI header field; 

B. include in the Contact header field: 

a. a public GRUU or temporary GRUU as specified in 3GPP TS 24.229 [2] if a GRUU was received at 
registration; and 

b. the media feature-tag g.3gpp.mid-call as described in annex C; and 

C. the SDP offer wdth: 

a. the same amount of the media descriptions as in the "body" URI header field in the URI in the Refer-To 
header field of the received SIP REFER request; 

b. each "m=" line having the same media type as the corresponding "m=" line in the "body" URI header 
field in the URI in the Refer-To header field of the received SIP REFER request; 

c. port set to zero value in each "m=" line whose corresponding "m=" line in the "body" URI header field in 
the URI in the Refer-To header field of the received SIP REFER request has port with zero value; and 

d. all media offered with sendonly or inactive directionaUty. 

NOTE 2: port can be sent to zero or non zero value for the offered "m=" line whose corresponding "m=" line in the 
"body" URI header field in the URI in the Refer-To header field of the received SIP REFER request has 
port with nonzero value. 



9.3 sec AS 



9.3.1 Distinction of requests sent to tine SCC AS 

The SCC AS needs to distinguish between the following initial SIP INVITE requests to provide specific functionaUty 
relating to access transfer: 

SIP INVITE requests routed to the SCC AS containing a STI belonging to the subscribed user in the Replaces 
header field or Target-Dialog header field. In the procedures below, such requests are known as "SIP INVITE 
requests due to STI ". 

SIP INVITE requests routed to the SCC AS containing a static STI in the Request-URI. In the procedures 
below, such requests are known as "SIP INVITE requests due to static STI". 

- SIP INVITE requests routed to the SCC AS containing either a static STN, a STN-SR or an IMRN (as 

described in 3GPP TS 24.292 [4]) in the Request-URI. In the procedures below, such requests are known as 
"SIP INVITE requests due to static STN ". 

NOTE: The media streams that need to be transferred are identified using information described in the subsequent 
sections. 

Other SIP initial requests for a dialog and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [2]. 
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9.3.2 sec AS procedures for PS to CS access transfer 

When the SCC AS receives a SIP INVITE request due to STI on the Target Access Leg, the SCC AS shall follow the 
procedures specified in subclause 10.3.2. 

When the SCC AS receives SIP INVITE request due to static STN, the SCC AS shall associate the SIP INVITE request 
with an ongoing SIP dialog based on information associated with the received IMRN (as described in 
3GPP TS 24.292 [4]) or based on information from the SIP History-Info header field and P-Asserted header field and 
send a SIP re-INVITE request towards the remote UE using the existing established dialog. By an ongoing SIP dialog, it 
is meant a dialog for which a SIP 2xx response to the initial SIP INVITE request has been sent or received. Multiple 
dialogs associated with the same SC UE may have been anchored when the SCC AS receives a SIP INVITE request due 
to static STN. This can occur in the event that the UE does not succeed in releasing all inactive dialogs or if the UE 
applies the MSC Server assisted mid-call feature. The identification of the associated dialog is subject to the following 
conditions: 

1 . if only one SIP dialog exists for the user identified in the P-Asserted-Identity header field and a SIP 2xx response 
has been sent and there is active audio media, then continue the session transfer with the active audio media SIP 

dialog; 

2. if no SIP dialogs exist for the user identified in the P-Asserted-Identity header field where there is active audio 
media and a SIP 2xx response has been sent and the SCC AS does not apply the MSC Server assisted mid-call 
feature as specified in subclause 9.3.2A, then send a SIP 480 (Temporarily Unavailable) response to reject the 
SIP INVITE request relating to the session transfer; 

3. if more than one SIP dialog exists for the user identified in the P-Asserted-Identity header field for which SIP 
2xx responses have been sent and there is active audio media on each of them, then the SCC AS shall perform 
session transfer procedures for the dialog that originates from the same device that initiated the received INVITE 
request due to static STN. If more than one such dialogs exists from the same device, the SCC AS shall proceed 
with the next step in this list; and 

NOTE 1 : Whether the dialog originates from the same UE as the received SIP INVITE request is determined based 
on local information and information related to the correlation MSISDN or the Instance-ID of the 
originating user as determined via registration procedures as defined in subclause 6.3. 

4. if more than one SIP dialog exists for the user identified in the P-Asserted-Identity header field and exactly one 
dialog exists where there is active audio media and a SIP 2xx response has been sent for that dialog, then: 

- if the SCC AS does not apply the MSC Server assisted mid-call feature as specified in subclause 9.3.2A, then 
the SCC AS may release the inactive audio media dialogs and continue the session transfer procedures with 
the active audio media SIP dialog; or 

if the SCC AS is not able to identify one dialog for session transfer, then the SCC AS shall send a SIP 480 
(Temporarily Unavailable) response to reject the SIP INVITE request relating to the session transfer. 

5. if more than one SIP dialog with active audio media exist for the user identified in the P-Asserted-Identity 
header field and a SIP 2xx response has been sent for that dialog, then: 

- if the SCC AS does not apply the MSC Server assisted mid-call feature as specified in subclause 9.3.2A, the 
SCC AS may release all SIP dialogs with audio media of the user identified in the P-Asserted-Identity header 
field for which a SIP 2xx response has been sent except the dialog with the active audio media that was most 
recently made active and continue the session transfer procedures; or 

- if the SCC AS is not able to identify one dialog for session transfer, then the SCC AS shall send a SIP 480 
(Temporarily Unavailable) response to reject the SIP INVITE request relating to the session transfer. 

Continuing the session transfer procedures, the SCC AS shall populate the SIP re -INVITE request as follows: 

1) set the Request-URI to the URI contained in the Contact header field returned at the creation of the dialog with 
the remote UE; and 

2) a new SDP offer, including the media characteristics as received in the SIP INVITE request due to static STN, 
by following the rules of 3GPP TS 24.229 [2]. 

Upon receiving the SIP ACK request from the IM CN subsystem, then: 
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if the source access leg contains only one audio media components the SCC AS shall initiate release of the 
source access leg by sending a SIP BYE request toward the S-CSCF for sending to the served SC UE; or 

If the Source Access Leg contains media components other than audio media component, the SCC AS should 
send a re-INVITE request to update the source access leg. 

9.3.2A SCC AS procedures for PS to CS access transfer with MSC server 
assisted mid-call feature 

The SCC AS shall apply the MSC Server assisted mid-caU feature if 

1 . the Contact header field of the SIP INVITE request due to static STN includes the feature-tag g.3gpp. mid-call as 
specified in annex C; 

2. at least one active audio media dialog exists for the user identified in the P-Asserted-Identity header field and the 
Contact header field provided by the SC UE at the establishment of the active audio media dialog which has 
been most recently made active includes the media feature-tag g.3gpp. mid-call as described in annex C 

3. the SCC AS supports the MSC Server assisted mid-call feature according to operator policy; and 

4. the SCC AS is aware that all MSC Servers in the network where the UE is registered which can be involved in 
the SRVCC procedures support the MSC Server assisted mid-call feature. 

When the SCC AS applies the MSC Server assisted mid-call feature, in addition to the procedures described in 
subclause 9.3.2, the SCC AS shall, before determining that the SCC AS is not able to identify one dialog for session 
transfer, proceed as follows: 

1 . if more than one SIP dialog exists for the user identified in the P-Asserted-Identity header field, and exactly one 
active audio media dialog exists, and a SIP 2xx response has been sent for that dialog and there is at least one 
remaining inactive audio media dialog, then the SCC AS may release all inactive audio media dialogs except the 
dialog with the audio media which became inactive most recently and continue the session transfer procedures 
with the active audio media SIP dialog; and 

2. if more than one active audio media SIP dialog exists for the user identified in the P-Asserted-Identity header 
field and a SIP 2xx response has been sent for these dialogs then the SCC AS may release all dialogs with audio 
media except two dialogs with the audio media which became active most recently and continue the session 
transfer procedures with the dialog with the audio media which became active most recently. 

Editor's note: transport of the session state information is FES 

When the SCC AS applies the MSC Server assisted mid-call feature, in addition to the procedures described in 
subclause 9.3.2, the SCC AS shall include the media feature-tag g.3gpp. mid-call as described in annex C in the Contact 
header field of the SIP 2xx response to the SIP INVITE request due to static STN. 

If the SCC AS applies the MSC Server assisted mid-call feature, two SIP dialogs with an audio media exist for the user 
identified in the P-Asserted-Identity header field and a SIP 2xx response has been sent for those dialogs then the SCC 
AS shall send a SIP REFER request towards the MSC Server in accordance with the procedures specified in 
3GPP TS 24.229 [2], IETF RFC 3515 [13] and IETF RFC 4488 [20] in the dialog created by the SIP INVITE request 
due to static STN. The SCC AS shall populate the SIP REFER request as follows: 

1. the Refer-Sub header field with value "false" as specified in IETF RFC 4488 [20]; 

2. the Supported header field with value "norefersub" as specified in IETF RFC 4488 [20]; 

3. the Refer-To header field containing the information related to the session with an audio media other than the 
session associated with the SIP INVITE request due to static STN, i.e. set to the URI provided by SCC AS in the 
Contact header field to the SC UE during the session establishment and the following URI header fields: 

A. the Target-Dialog URI header field populated as specified in IETF RFC 4538 [11], containing the dialog 
identifier of the session with the SC UE; 

B. the Require URI header field populated with the option tag value "tdialog"; 
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C. the To URI header field populated as specified in IETF RFC 3261 [19], containing the P-Asserted-Identity 
provided by the remote UE during the session establishment; 

D. the From URI header field populated as specified in IETF RFC 3261 [19], containing the pubhc user identity 
of the SC UE provided during the session estabUshment; 

E. the Content-Type header field with "application/sdp"; and 

F. the "body" URI header field populated with an SDP body describing the media streams as negotiated in the 
session with the remote UE. 

4. the Content-Type header field with the value set to MIME type as specified in the annex D.1.3; and 

5. a XML body compliant to the XML schema specified in the annex D. 1 .2. 

9.3.3 sec AS procedures for CS to PS access transfer 

When the SCC AS receives a SIP INVITE request due to STI on the Target Access Leg, the SCC AS shall follow the 
procedures specified in subclause 10.3.2. 

When the SCC AS receives a SIP INVITE request due to static STI, the SCC AS shall associate the SIP INVITE 
request with an ongoing SIP dialog. By an ongoing SIP dialog, it is meant a dialog for which a SIP 2xx response to the 
initial SIP INVITE request has been sent or received. Multiple dialogs associated with the same SC UE may have been 
anchored when the SCC AS receives a SIP INVITE request due to static STL This can occur in the event that the UE 
does not succeed in releasing all inactive audio media dialogs or if the UE supports the MSC Server assisted mid-call 
feature, in which case the identification of the associated dialog is subject to the following conditions: 

1 . if only one SIP dialog exists for the user identified in the P-Asserted-Identity header field and a 2xx response has 
been sent and there is active audio media, then continue the session transfer procedures; 

2. if no SIP dialogs exist for the user identified in the P-Asserted-Identity header field where there is active audio 
media and a SIP 2xx response has been sent and the SCC AS does not apply the MSC Server assisted mid-call 
feature as specified in subclause 9.3.4, then send a SIP 480 (Temporarily Unavailable) response to reject the SIP 
INVITE request relating to the session transfer; 

3. if more than one SIP dialog exists for the user identified in the P-Asserted-Identity header field and exactly one 
dialog exists where there is active audio media and a SIP 2xx response has been sent for that dialog, then: 

A. if the remaining dialogs have inactive audio media and the SCC AS does not apply the MSC Server assisted 
mid-call feature as specified in subclause 9.3.4, then the SCC AS may release the inactive audio media 
dialogs and continue the session transfer procedures with the active audio media SIP dialog; and 

4. if the SCC AS is not able to identify one dialog for session transfer, then the SCC AS shall send a SIP 480 
(Temporarily Unavailable) response to reject the SIP INVITE request relating to the session transfer. 

Continuing the session transfer procedures, the SCC AS sends a SIP re-INVITE request towards the remote UE using 
the existing established dialog. The SCC AS shall populate the SIP re-INVITE request as follows: 

1) set the Request-URI to the URI contained in the Contact header field returned at the creation of the dialog with 
the remote UE; and 

2) a new SDP offer, including the media characteristics as received in the SIP INVITE request due to the static STI, 
by following the rules of 3GPP TS 24.229 [2J. 

Upon receiving the SIP ACK request originated from the UE, the SCC AS shall initiate release of the source access leg 
by sending a SIP BYE request over the source access leg. 

If, subsequent to initiating the SIP re-INVITE request to the remote UE, and prior to the SIP ACK request originated 
from the UE being received from the IM CN subsystem for the source access leg, the SCC AS decides (for any reason) 
to reject the session transfer request back to the UE (e.g. by sending a 4xx response), the SCC AS shall release the 
target access leg and maintain the source access leg. 
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9.3.4 sec AS procedures for CS to PS access transfer with MSG server 
assisted mid-call feature 

The sec AS shall apply the MSC Server assisted mid-call feature if 

1. the Contact header field of the SIP ESTVITE request due to static STI includes the feature-tag g.Bgpp.mid-call as 
specified in annex C; 

2. the sec AS supports the MSC Server assisted mid-call feature according to operator policy; and 

3. the sec AS is aware that all MSC Servers in the network where the UE is registered which can be involved in 
the SRVCC procedures support the MSC Server assisted mid-call feature. 

When the SCC AS applies the MSC Server assisted mid-call feature, in addition to the procedures described in 
subclause 9.3.3, SCC AS shall, before determining that the SCC AS is not able to identify one dialog for session 
transfer, proceed as follows: 

1. if more than one SIP dialog exists for the user identified in the P-Asserted-Identity header field, and exactly one 
dialog exists where there is active audio media, and a SIP 2xx response has been sent for that dialog and there is 
at least one remaining inactive audio media dialog then the SCC AS may release all inactive audio media dialogs 
except the dialog with the audio media which became inactive most recently and continue the session transfer 
procedures with the active audio media SIP dialog. 

When the SCC AS applies the MSC Server assisted mid-call feature, in addition to the procedures described in 
subclause 9.3.2, the SCC AS shall include the media feature-tag g.3gpp.mid-call as described in annex C in the Contact 
header field of the SIP 2xx response to the SIP INVITE request due to static STI. 

If the SCC AS applies the MSC Server assisted mid-call feature, two SIP dialogs with an audio media exist for the user 
identified in the P-Asserted-Identity header field and a SIP 2xx response has been sent for those dialogs then the SCC 
AS shall send a SIP REFER request towards the SC UE in accordance with the procedures specified in 
3GPP TS 24.229 [2], IETF RFC 3515 [13] and IETF RFC 4488 [20] in the dialog created by the SIP INVITE request 
due to static STI. The SCC AS shall populate the SIP REFER request as follows: 

1. the Refer-Sub header field with value "false" as specified in IETF RFC 4488 [20]; 

2. the Supported header field with value "norefersub" as specified in IETF RFC 4488 [20]; 

3. the Refer-To header field containing the information related to the session with an audio media other than the 
session associated with the SIP INVITE request due to static STN, i.e. set to the URl provided by SCC AS in the 
Contact header field to the SC UE during the session estabhshment and the following URI header fields: 

A. the Target-Dialog URI header field populated as specified in IETF RFC 4538 [11], containing the dialog 
identifier of the session with the MSC Server; 

B. the Require URI header field populated with the option tag value "tdialog"; 

C. the To URI header field populated as specified in IETF RFC 3261 [8], containing the P-Asserted-Identity 

provided by the remote UE during the session establishment; 

D. the From URI header field populated as specified in IETF RFC 3261 [8], containing the public user identity 
of the SC UE provided during the session estabhshment; 

E. the Content-Type header field with "application/sdp"; and 

F. the "body" URI header field populated with an SDP body describing the media streams as negotiated in the 
session with the remote UE. 

4. the Content-Type header field with the value set to MIME type specified in the annex D.1.3; and 

5. a 3GPP IM CN subsystem XML body compliant to the XML schema specified in the annex D.1.2. 
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9.4 MSG Server enhanced for ICS 

9.4.1 MSG Server enhanced for ICS procedures for PS to CS session 
continuity with MSC server assisted mid-call feature 

Editor's note: it is FFS how to ensure that the UE and the MSC Server would use the same transaction identifers for 
the conferencing sessions 

Editor's note: transport of the session state information is FFS 

In addition to the procedures specified in 3GPP TS 29.292 [18], the MSC Server enhanced for ICS supporting the MSC 
Server assisted mid-call feature shall populate the SIP INVITE request as follows: 

1. the Supported header field containing the option-tag "norefersub" specified in IETF RFC 4488 [20]; 

2. the Accept header field containing the MIME type as specified in annex D.1.3; and 

3. include in the Contact header field the media feature-tag g.3gpp. mid-call as described in annex C. 

NOTE 1: Since the MSC Server is not able to distinguish the dual radio access transfer from the regular session set 
up, the information elements above are added to every SIP INVITE request sent by the MSC Server. 

Upon receiving a SIP REFER request 

1. with the Refer-Sub header field containing "false" value; 

2. with the Supported header field containing "norefersub" value; 

3. with the Refer-To header field containing a SIP URI with the Target-Dialog URI header field; 

4. sent inside an existing SIP dialog: 

A. which was originated by the MSC Server; and 

B. where the remote UE included the feature-tag g.3gpp. mid-call as specified in annex C in the Contact header 
field of the SIP 2xx response to the SIP INVITE request; and 

5. containing a MIME body of MIME type specified in the annex D.1.3; 

and if the MSC Server enhanced for ICS supports the MSC Server assisted mid-call feature, then the MSC Server 
enhanced for ICS shall: 

1. handle the SIP REFER request as specified in 3GPP TS 29.292 [18], IETF RFC 3515 [13] and 
IETF RFC 4488 [20]; and 

2. send a SIP INVITE request for transfer of an additional inactive session not using ICS capabilities in accordance 
with the procedures specified in 3GPP TS 29.292 [18] and IETF RFC 3515 [13]. Additionally, the MSC Server 
enhanced for ICS shall populate the SIP INVITE request as follows: 

A. header fields which were included as URI header fields in the URI in the Refer-To header field of the 
received SIP REFER request as specified in IETF RFC 3261 [19] except the "body" URI header field; 

B. include in the Contact header field the media feature-tag g.3gpp.mid-call as described in annex C; and 

C. the SDP offer with: 

a. the same amount of the media descriptions as in the "body" URI header field in the URI in the Refer-To 
header field of the received SIP REFER request; 

b. each "m=" line having the same media type as the corresponding "m=" line in the "body" URI header 
field in the URI in the Refer-To header field of the received SIP REFER request; 

c. port set to zero value in each "m=" line whose corresponding "m=" line in the "body" URI header field in 
the URI in the Refer-To header field of the received SIP REFER request has port with zero value; and 
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d. all media offered with sendonly or inactive directionality; and 

NOTE 2: port can be sent to zero or non zero value for the offered "m=" line whose corresponding "m=" line in the 
"body" URI header field in the URI in the Refer-To header field of the received SIP REFER request has 
port with nonzero value. 

The MSG Server enhanced for ICS shall associate the SIP INVITE request for an additional inactive session with CS 
call with transaction identifier calculated as in the table 9.2.1A-1 and TI flag value as in mobile originated call. 

9.4.1 A MSG Server enhanced for ICS procedures for PS to CS session 

continuity witin MSC server assisted mid-call feature for speech and 
video session 

If the MSC Server enhanced for ICS supports the MSC Server assisted mid-call feature, upon receiving the session state 
information which indicates an inactive speech and video session, the MSC Server enhanced for ICS shall send a SIP 
INVITE request for the additional inactive speech and video session as described in subclause 9.4. lA. 

NOTE 1: If due to some reason (i.e. the current RAN type not supporting video, lack of resource, etc.) the video 

media can not be supported in CS network for the speech and video session, then the MSC Server can set 
the port to zero in the "m=" line for the video media in the SDP offer of the SIP INVITE request for the 
additional inactive session, so as to inform the SCC AS that the video media is deleted and only the audio 
media of the speech and video session is transferred to CS. 

NOTE 2: After successful transfer of a speech and video session and a speech session from PS to CS, if messages 
are received from the UE to switch between the two sessions (i.e. HOLD/Release message to hold/release 
the active session and Retrieve message to retrieve the inactive session), the MSC Server enhanced for 
ICS can perform the procedures as specified in 3GPP TS 29.292 [18], with the addition that the MSC 
Server enhanced for ICS can complete the in-call modification or Redial procedures as specified in 
3GPP TS 24.008 [8] to change the shared CS bearer of the two sessions from speech to multimedia, or 
vice versa, before sending a SIP UPDATE or SIP re-INVITE message to the SCC AS to resume the 
inactive session. 



1 Roles for PS-PS access transfer 

10.1 Introduction 

This clause specifies the procedures for PS-PS access transfer for both full media transfer case and partial media 
transfer case. Procedures are specified for the SC UE and the SCC AS. 

10.2 SCUE 

The SC UE may be engaged in one or more ongoing sessions before performing access transfer. By an ongoing session, 
it is meant a session for which the SIP 2xx response for the initial SIP INVITE request to establish this session has been 
sent or received. 

The SC UE may receive the operator policy via OMA Device Management, see 3GPP TS 24.216 [5]. When the SC UE 
receives the operator policy, for each session to be transferred, it shall take the operator policy into account when 
deciding to perform the following: 

- selecting the access for initiating the PS-PS transfer; 

- determining whether to transfer fuU or partial media during PS-PS transfer; or 

- determining whether to add or remove media during the PS-PS transfer. 

If the SC UE is configured with the operator policy (e.g. via OMA Device Management as described in 

3GPP TS 24.216 [5]) then, for each media or group of media contained in the MediaorGroup node, the SC UE shall: 
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1) restrict originating sessions and session transfer towards the access networks contained in the 
RestrictedAccessNetworkType node and; 

2) consider the list of access networks contained in the PreferredAccessNetworks node in the order of priority from 
the access networks such that, when available, the highest priority access network can be used for originating 
sessions and session transfer procedures; 

3) if a new access network gets available- transfer media components to a higher priority target network than the 
current access network based on the value contained in the SC_media_transfer node value. If the 
SC_media_transfer node value is: 

"shall" the UE shall start a session transfer according to the home operator' s list of preferred access networks 
contained in the PreferredAccessNetworks node; 

"should" the UE is recommended to start session transfer according to the home operator' s list of preferred 

access networks contained in the PreferredAccessNetworks node. The UE can evaluate if session transfer is 
possible and desirable after having taken into account the Local Operating Environment Information; 

"may" the UE can decide whether or not to start session transfer in accordance with user preferences if 
configured in the UE. The UE can evaluate if session transfer is possible and desirable after having taken into 
account the Local Operating Environment Information. If user preferences are not configured, the UE can 
evaluate the home operator' s list of preferred access networks contained in the PreferredAccessNetworks 
node. 

4) decide whether to keep or drop non transferable media components in the case of partial session transfer based 
on the SC_non_transferrable_media node value. 

The SC UE shall follow the procedures specified in subclause 6.1 to perform IMS registration over the Target Access 
Leg before performing PS-PS access transfer. 

10.2.1 Full session transfer 

To initiate PS-PS access transfer for a session, the SC UE shall send a SIP INVITE request over the Target Access Leg 
in accordance with UE procedures specified in 3GPP TS 24.229 [2]. The SC UE shall populate the SIP INVITE request 
as follows: 

1. the Request-URI set to the URI contained in the Contact header field returned at the creation of the dialog over 
the Source Access Leg; 

2. include in the Contact header field: 

A a public GRUU or temporary GRUU as specified in 3GPP TS 24.229 [2] if a GRUU was received at 
registration; and 

B the media feature tag g.3gpp.ics set to "principal" as specified in annex B of 3GPP TS 24.292 [4]; 

3. select one of the following options: 

A. if usage of SIP Replaces extension is selected: 

a. the Replaces header field populated as specified in IETF RFC 3891 [10], containing the dialog identifier 
of the session to be transferred; and 

b. the Require header field populated with the option tag value "replaces"; 

B. if usage of SIP Target-Dialog extension is selected: 

a. the Target-Dialog header field populated as specified in IETF RFC 4538 [11], containing the dialog 
identifier of the session to be transferred; and 

b. the Require header field populated with the option tag value "tdialog" ; and 

4. the SDP payload set for the media component(s) to be transferred, in accordance with the UE SDP origination 
procedures specified in 3GPP TS 24.229 [2]. The SDP shall contain the same number of media lines, each 
corresponding to one of the media components in the original session, unless media components need to be 
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added. Each media line shall indicate the same media type as its corresponding media component in the original 
session and shall contain at least one codec that was negotiated during the original session. 

A- If the SC UE determines to remove a media component during the transfer, then the media Une for this media 
component shall include a port number with value zero; and 

B- If the SC UE determines to add new media component(s) during the transfer, then one additional media line 
with the desired media type and codecs shall be added for each new media component at the end of the SDP. 

NOTE: If an SC UE is an ICS UE with an ongoing session using CS bearer and Gm reference point for service 

control signalling, the SC UE can perform an access transfer of the service control signalling from the 
current IP-CAN to a new IP-CAN with the same capabilities (i.e. supporting CS and PS bearers, 
simultaneously) while retaining the media component in the CS access network by including the 
description of audio/video media over a circuit switched bearer in the SDP of the access transfer request, 
so that service continuity of the session is maintained. 

Upon receiving SIP 2xx response for the SIP INVITE request sent over the Target Access Leg and sending SIP ACK 
request, if the dialog over the Source Access Leg is still active, the SC UE shall send a SIP BYE request to the SCC AS 
over the Source Access Leg to terminate the original session. 

If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request sent over the Target Access Leg, then PS- 
PS access transfer has not completed successfully and the call will continue in the Source Access Leg. 

10.2.1 A Additional procedures for full session transfer when IVISC server 

assisted mid-call feature is supported 

In addition to the procedures described in subclause 10.2.1, if the SC UE supports the MSC Server assisted mid-call 
feature, the SC UE shall include in the Contact header field of the SIP INVITE request the media feature-tag as 
described in annex C. 

1 0.2.2 Partial session transfer 

To initiate PS-PS access transfer for a session, the SC UE shall send a SIP INVITE request over the Target Access Leg 
in accordance with UE procedures specified in 3GPP TS 24.229 [2]. The SC UE shall populate the SIP INVITE request 
as follows: 

1 . the Request-URl set to the URI contained in the Contact header field returned at the creation of the dialog over 

the Source Access Leg; 

2. include in the Contact header field: 

A. a public GRUU or temporary GRUU as specified in 3GPP TS 24.229 [2] if a GRUU was received at 

registration; and 

B. the media feature tag g.3gpp.ics set to "principal" as specified in annex B of 3GPP TS 24.292 [4] ; 

3. the Require header with the option tag 'tdialog' included; 

4. the Target-Dialog header populated as specified in IETF RFC 4538 [11], containing the dialog identifier of the 

session to be transferred; and 

5. the SDP payload set for the media component(s) to be transferred, in accordance with the UE SDP origination 
procedures specified in 3GPP TS 24.229 [2]. The SDP shall contain the same number of media lines in the same 
order, each corresponding to one of the media components in the original session, unless media components 
need to be added during the session transfer. Each media line shall indicate the same media type as its 
corresponding media component in the original session and shall contain at least one codec that was negotiated 
during the original session. 

A. If the SC UE determines to keep the media component on the Source Access Leg, then the media line for 
this media component shall include a port number with value zero; and 
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If the SC UE determines to add new media component(s) during the transfer, then one additional media 
hne with the desired media type and codecs shall be added for each new media component at the end of 
the SDP. 

If an SC UE is an ICS UE with an ongoing session using CS bearer and Gm reference point for service 
control signalling, the SC UE can perform an access transfer of the service control signalling from the 
current IP-CAN to a new IP-CAN with the same capabiUties (i.e. supporting CS and PS bearers, 
simultaneously) while retaining the media component in the CS access network by including the 
description of audio/video media over a circuit switched bearer in the SDP of the access transfer request, 
so that service continuity of the session is maintained. 

Upon receiving SIP 2xx response for the SIP INVITE request sent over the Target Access Leg and sending SIP ACK 
request, the SC UE shall send a SIP re-INVITE request to the SCC AS over the Source Access Leg to update the 
original session. The SC UE shall populate the SIP re-INVITE request as follows: 

1. the SDP payload set for all the media component(s) within the original session, in accordance with the UE SDP 
origination procedures specified in 3GPP TS 24.229 [2]. The port number for a media component shall be set to 
zero if that media component has been transferred to the Target Access Leg or has to be removed. 

If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request sent over the Target Access Leg, then PS- 
PS access transfer has not completed successfully and the call will continue in the Source Access Leg. 

1 0.2.3 Additional procedures for partial session transfer when MSG server 
assisted mid-call feature is supported 

In addition to the procedures described in subclause 10.2.2, if the SC UE supports the MSC Server assisted mid-call 
featiu'e, the SC UE shall include in the Contact header field of the SIP INVITE request the media feature-tag as 
described in annex C. 



10.3 SCC AS 

1 0.3.1 Distinction of requests sent to the SCC AS 

The SCC AS needs to distinguish between the following initial SIP INVITE requests to provide specific functionality 
relating to access transfer: 

SIP INVITE requests routed to the SCC AS containing a STI belonging to the subscribed user in the Replaces 
header or Target-Dialog header. In the procedures below such requests are known as "SIP INVITE requests due 
to STI". 

NOTE: The media streams that need to be transferred are identified using information described in the subsequent 
sections. 

Other SIP initial requests for a dialog and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [2]. 

1 0.3.2 PS to PS access transfer procedures at the SCC AS 

When the SCC AS receives a SIP INVITE request on the Target Access Leg due to STI, the SCC AS shall: 

associate the SIP INVITE received on the Target Access Leg with an ongoing SIP dialog i.e. identify the 
Source Access Leg. The Source Access Leg is identified by matching the dialog ID present in the Replaces (see 
IETF RFC 3891 f 101) or Target Dialog header (see IETF RFC 4538 [11]) of the SIP INVITE with an ongoing 
dialog. By an ongoing SIP dialog, it is meant a dialog for which a SIP 2xx response to the initial SIP INVITE 
request has been sent or received; 

if the SCC AS is unable to associate the SIP INVITE with a unique ongoing dialog, send a SIP 480 
(Temporarily Unavailable) response to reject the SIP INVITE request relating to the access transfer and not 

processes the remaining steps; 

if the SIP INVITE request contains a Replaces header: 
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a) follow the procedures defined in IETF RFC 3891 [10] for replacing the Source Access Leg with the SIP 
request received on the Target Access Leg, including terminating the Source Access Leg by sending a SIP 
BYE towards the SC UE in accordance with 3GPP TS 24.229 [8]; and 

b) send a SIP re-INVITE request towards the remote UE using the existing estabUshed dialog. The SCC AS 
shall populate the SIP re-INVITE request as follows: 

1) set the Request-URI to the URI contained in the Contact header field returned at the creation of the dialog 
with the remote UE; and 

2) a new SDP offer, including the media characteristics as received in the SIP INVITE request due to STI 
received on the Target Access Leg, by following the rules of 3GPP TS 24.229 [2]. 

otherwise, if the SIP INVITE request contains a Target Dialog header: 

a) if the number of media lines in the Target Access Leg is less than the number of media lines in the Source 
Access Leg or the media type for the corresponding media lines is not the same as in the original session, 
send a SIP 4xx response to reject the SIP INVITE request relating to the access transfer and not process the 
remaining steps; 

b) otherwise, send a SIP re-INVITE request towards the remote UE using the existing estabUshed dialog. The 
SCC AS shall populate the SIP re-INVITE request as follows: 

1) set the Request-URI to the URI contained in the Contact header field returned at the creation of the dialog 
with the remote UE; and 

2) include a new SDP offer, following the rules specified in 3GPP TS 24.229 [2J, containing the following 
media information: 

- the media characteristics as received in the SIP INVITE request due to STI received on the Target 
Access Leg for media streams whose port is not set to zero; and 

for the media streams in the SIP INVITE request due to STI whose port is set to zero, include the 
corresponding media characteristics of those streams from the Source Access Leg, 

c) for a full media transfer, send a SIP BYE towards the SC UE in accordance with 3GPP TS 24.229 [2]; 
otherwise, for a partial media transfer, after receiving the SIP ACK request from the SC UE on the Target 
Access Leg, upon receiving an update (e.g. SIP re-INVITE) from the SC UE on the Source Access Leg, 
process the update request in accordance with 3GPP TS 24.229 [2]. 

If, subsequent to initiating the SIP re-INVITE request to the remote UE, and prior to the SIP ACK request being 
received on the Target Access Leg, the SCC AS decides (for any reason) to reject the access transfer request (e.g. by 
sending a 4xx response), the SCC AS shall release the Target Access Leg, retain the Source Access Leg, and update the 
remote leg to match the Source Access Leg. 

1 0.3.3 Additional SCC AS procedures for PS to PS access transfer when 
IVISC server assisted mid-call feature is supported 

If: 

1 . the SCC AS supports the MSC Server assisted mid-call feature according to operator policy; 

2. the media feature-tag g.3gpp.mid-call as described in annex C is included in the Contact header field of the SIP 
INVITE request due to STI; and 

3. the SCC AS is aware that all MSC Servers in the network where the UE is registered which can be involved in 
the SRVCC procedures support the MSC Server assisted mid-call feature; 

then the SCC AS shall include the media feature-tag g.3gpp.mid-call as described in annex C in the Contact header field 
of the SIP 2xx response to the SIP INVITE request due to STI in addition to the procedures described in 
subclause 10.3.2. 
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1 1 Roles for PS-PS access transfer in conjunction with 
PS-CS access transfer 

11.1 Introduction 

This clause specifies the procedures for PS-PS access transfer in conjunction with PS-CS access transfer. Procedures are 
specified for the SC UE and the SCC AS. For SC UE or SCC AS not supporting ICS procedures, PS-PS access transfer 
with a remote end in conjunction with PS-CS access transfer with the same remote end is only possible when the UE is 
active in a single CS session with full-duplex speech with the remote end i.e. support of session transfer with more than 
one session containing full-duplex speech component is not provided. 

11.2 SCUE 

1 1 .2.1 SC UE procedures for PS to PS+CS access transfer 

11.2.1.1 General 

The SC UE may be engaged in one or more ongoing IMS sessions before performing access transfer. By an ongoing 
session, it is meant a session for which the SIP 2xx response for the initial SIP INVITE request to estabUsh this session 
has been sent or received. 

1 1 .2.1 .2 SC UE procedures for PS to PS+CS access transfer using ICS 

If IMS service continuity using ICS is enabled then if the SC UE is using Gm, then for each session to be transferred 
and starting with the session with active full-duplex speech component, the SC UE shall send a SIP INVITE request to 
the SCC AS as specified for call origination for ICS UE using Gm in 3GPP TS 24.292 [4]. The SC UE shall populate 
the SIP INVITE request as specified for PS-PS access transfer with full media transfer in subclause 10.2.1. The SC UE 
shall indicate in the SIP INVITE request that the speech media is using CS bearer. When sending the SIP INVITE 
request for the sessions with inactive full-duplex speech component and if precondition is used, the SC UE shall 
indicate that the related local preconditions for the speech component are met. 

If service control over Gm for the CS bearer is retained on the source access leg, the SC UE shall: 

- send an SIP INVITE request as specified for partial session transfer in subclause 10.2.2. indicating transfer of 
non-speech media to the target access leg; and 

send a SIP re-INVITE request over the source access leg indicating that the speech media is to be transferred to a 
CS bearer as described in 3GPP TS 24.292 [4] subclause 8.2.2.2. If other media components are retained or 
added on the source access leg, then these are included in the SDP offer. 

For the session with active full-duplex speech component, upon receiving the PSI DN from the SCC AS, the SC UE 
shall follow the procedures for call origination for ICS UE using Gm in 3GPP TS 24.292 [4] to set up the CS bearer. 

1 1 .2.1 .3 SC UE procedures for PS to PS+CS access transfer not using ICS 

If the SC UE is not using ICS capabiUties, then access transfer is only possible when the UE is active in a single session 
with full-duplex speech media component. For the non-speech components to be transferred to the PS Target Access 
Leg, the SC UE shall send a SIP INVITE request to the SCC AS as specified for PS-PS access transfer with partial 
media transfer in subclause 10.2.1. For the speech component to be transferred to the CS Target Access leg, the SC UE 
shall send to the SCC AS a CS call setup message, e.g., CC_SETUP as specified in 3GPP TS 24.008 [8]. When sending 
the CC_SETUP, the SC UE shall populate the CC_SETUP as follows: 

1) the called party BCD number information element set to the STN. 

Upon receiving the SIP 2xx response from the SCC AS for the PS Target Access Leg and sending SIP ACK request and 
upon receiving CS call setup confirmation message, e.g. CC_CONNECT message, for the CS Target Access Leg, the 
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SC UE shall send a SIP BYE request to terminate the Source Access Leg, following the procedures specified in 
3GPP TS 24.229 [2]. 

If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request for the PS Target Access leg and receives 
CS caU setup failure message for the CS Target Access Leg, then session transfer has not occurred and the call will 
continue in the original domains. 

If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request for the PS Target Access Leg and 
receives CS call setup confirmation message for the CS Target Access Leg, then the session transfer is only successful 
for part of the media components. The SC UE shall update the Source Access leg by following the procedures specified 
for PS-PS access transfer with partial media transfer in subclause 10.2.2 to indicate that all media components other 
than the speech component are still maintained on the Source Access Leg. 

If the SC UE receives CS call setup failure message for the CS Target Access Leg but receives a SIP 2xx response for 
the PS Target Access Leg, then the session transfer is only successful for part of the media components. Upon sending 
SIP ACK request, the SC UE shall update the Source Access leg by following the procedures specified for PS-PS 
access transfer with partial media transfer in subclause 10.2.2 to indicate that the speech component is still maintained 
on the Source Access Leg. 

1 1 .2.2 SC UE procedures for PS+CS to PS access transfer 

11.2.2.1 General 

The SC UE may be engaged in one or more ongoing sessions before performing access transfer. By an ongoing session, 
it is meant a CS call for which the CC CONNECT message has been sent or received or a call for which the SIP 2xx 
response for the initial SIP INVITE request to estabUsh this session has been sent or received. 

If not already registered over the PS Target Access Leg, the SC UE shall follow the procedures specified in 
subclause 6.2 to perform IM CN subsystem registration over the Target Access Leg before performing PS/CS to PS 
access transfer. 

1 1 .2.2.2 SC UE procedures for PS+CS to PS access transfer using ICS 

If IMS service continuity using ICS is enabled then if the original sessions are estabUshed using ICS capabilities, then 

for each session to be transferred and starting with the session with active fall-duplex speech media component, the SC 
UE shall send a SIP INVITE request to the SCC AS in accordance with the UE procedures specified in 
3GPP TS 24.229 [2]. The SC UE shall populate the SIP INVITE request as specified for PS-PS access transfer with full 
media transfer in subclause 10.2.1. The SC UE shall indicate in the SIP INVITE request that the speech media 
component is using PS media. 

Upon receiving SIP BYE request for the Source Access Leg, the SC UE shall follow the ICS using Gm procedures 
specified in 3GPP TS 24.292 [4] to release the session. The SC UE also releases the associated CS bearer if no other 
sessions depend on the CS bearer. 

1 1 .2.2.3 SC UE procedures for PS+CS to PS access transfer not using ICS 

If the original sessions are not established using ICS capabilities, then access transfer is only possible when the SC UE 
has a single session with active full-duplex speech media component. The SC UE shall send a SIP INVITE request to 
the SCC AS in accordance with the UE procedures specified in 3GPP TS 24.229 [2]. 

The SC UE shall populate the SIP INVITE request as follows: 

- the Request-URI set to static STI; 

- the Require header field including "replaces" option tag; 

- the Replaces header field populated as specified in IETF RFC 3891 [10], containing the dialog identifier of the 
session to be transferred on the PS Source Access Leg; and 

- the SDP payload set for the media component(s) to be transferred, in accordance the UE SDP origination 
procedures specified in 3GPP TS 24.229 [2]. The SDP shall contain media components in the following order: 
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1) The same number of media lines, each corresponding to one of the media components in the session on the 
PS Source Access Leg; Each media hne shall indicate the same media type as its corresponding media 
component in the original session and shall contain at least one codec that was negotiated during the original 
session. If the SC UE determines to remove a media component during the transfer, then the media Une for 
this media component shall include a port number with value zero; 

2) One speech media component to be transferred, corresponding to the speech media component in the session 
on the CS Source Access Leg; and 

3) If the SC UE determines to add new media component(s) during the transfer, then one additional media line 
with the desired media type and codecs shall be added for each new media component. 

If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request, then session transfer has not occurred 
and the call will continue in the original domains. 

1 1 .3 sec AS 

11 .3.1 Distinction of requests sent to tine SCC AS 

The SCC AS needs to distinguish between the following initial SIP INVITE requests to provide specific functionaUty 
relating to access transfer: 

SIP INVITE requests routed to the SCC AS containing a STI belonging to the subscribed user in the Replaces 
header field or Target-Dialog header field. In the procedures below, such requests are known as "SIP INVITE 
requests due to STI". 

SIP INVITE requests routed to the SCC AS containing either a static STN or an IMRN in the Request-URI. In 
the procedures below, such requests are known as "SIP INVITE requests due to static STN". 

SIP INVITE requests routed to the SCC AS containing a static STI in the Request-URI and a STI in the 
Replaces or Target-Dialog header field. In the procedures below, such requests are known as "SIP INVITE 
requests due to two STIs". 

NOTE: The media streams that need to be transferred are identified using information described in the subsequent 
subclauses 11.3.2 and 11.3.3. 

Other SIP initial requests for a dialog and requests for a SIP standalone transaction can be dealt with in any maimer 
conformant with 3GPP TS 24.229 [2]. 

1 1 .3.2 SCC AS procedures for PS to PS+CS access transfer 

When the SCC AS receives a SIP INVITE request due to STI on the Target Access Leg, the SCC AS shall follow the 
PS-PS Access Transfer procedures specified in subclause 10.3.2. If the SIP INVITE request includes an active speech 
media component using CS bearer, then the SCC AS shall follow the procedures for SCC AS for service control over 
Gm in 3GPP TS 24.292 [4] to send the PSI DN to the SC UE and wait for the SC UE to set up CS bearer before sending 
re-INVITE to the remote end. If service control over Gm is retained on the source access leg, and the SCC AS receives 
a re-INVlTE request indicating CS bearer on an existing session, the SCC AS shall follow procedures as described in 
3GPP TS 24.292 [4] subclause 8.4.2. 

When the SCC AS receives a SIP INVITE request due to static STN on the Target Access Leg, the SCC AS shall 
follow the PS-CS Access Transfer procedures specified in subclause 9.3.2. However, as the Source Access Leg contains 
media components other than speech component, the SCC AS does not initiate release for Source Access Leg. 

1 1 .3.3 SCC AS procedures for PS+CS to PS access transfer 

When the SCC AS receives a SIP INVITE request due to STI on the Target Access Leg, the SCC AS shall follow the 
PS-PS access transfer procedures specified in subclause 10.3.2. 

When the SCC AS receives a SIP INVITE request due to two STIs on the Target Access Leg, the SCC AS shall: 
associate the SIP INVITE request received on the Target Access Leg with two ongoing sessions: 
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a) an ongoing SIP dialog on the PS Source Access Leg: This is done by matching the dialog ID present in the 
Replaces header field (see IETF RFC 3891 [10]) or Target-Dialog header field (see IETF RFC 4538 [11]) of 
the SIP INVITE request with an ongoing dialog. By an ongoing SIP dialog, it is meant a dialog for which a 
SIP 2xx response to the initial SIP INVITE request has been sent or received; 

b) a different ongoing SIP dialog with active full-duplex speech component: 

if the sec AS is unable to associate the SIP INVITE request with either one of the above two dialogs, send a 
SIP 480 (Temporarily Unavailable) response to reject the SIP INVITE request relating to the access transfer and 
not process the remaining steps; and 

if the session transfer is possible: 

a) follow the procedures defined in IETF RFC 3891 [10] for replacing the two sessions on the Source Access 
Legs with the SIP request received on the Target Access Leg, including terminating the two Source Access 
Legs by sending a SIP BYE request on each session towards the SC UE in accordance with 

3GPP TS 24.229 [2]; and 

b) send a SIP re-INVITE request towards the remote UE using the existing estabhshed dialog. The SCC AS 
shall populate the SIP re-INVITE request as follows: 

1) set the Request-URI to the URI contained in the Contact header field returned at the creation of the dialog 
with the remote UE; and 

2) a new SDP offer, including the media characteristics as received in the SIP INVITE request due to two 
STIs received on the Target Access Leg, by following the rules of 3GPP TS 24.229 [2]. 



1 2 Roles for PS-CS access transfer, Single Radio 

12.1 Introduction 

This clause specifies the procedures for PS-CS access transfer in Single Radio VCC. Procedures are specified for the 
SC UE and the SCC AS. For SC UE or SCC AS not supporting ICS procedures, PS-CS access transfer in SR-VCC is 
only possible when IMS service continuity is enabled, the UE is active in a single session with full-duplex speech i.e. 
support of session transfer with more than one session containing full-duplex speech component is not provided. 

12.2 SC UE procedures for PS to CS access transfer, SR-VCC 

12.2.1 General 

The SC UE may be engaged in one or more ongoing IMS sessions before SR-VCC access transfer is performed. By an 
ongoing session, it is meant a session for which the SIP 2xx response for the initial SIP INVITE request to establish this 
session has been sent or received. 

12.2.2 ICS-based 

If: 

- IMS service continuity using ICS is enabled; 

- the Gm reference point is retained upon PS handover procedure; 

- the SC UE is using ICS capabilities; and 

- SR-VCC procedures (as described in 3GPP TS 24.008 [8]) have been completed; 
the SC UE, in order to add Gm control for the newly established CS session, shall: 
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send a SIP re-INVITE request for each speech session to be transferred, starting with the session with active full- 
duplex speech component that was most recently made active; and 

within the SDP offer indicate the media line for all active and held audio streams as an audio stream over circuit 
switched bearer in accordance with 3GPP TS 24.292 [4]. If the precondition mechanism is used, the SC UE shall 
indicate the related local preconditions as met. 

NOTE: Within SR-VCC the handover is performed on PS level. Due to this, the SIP dialog established over the 
source PS access network stays the same after SR-VCC procedures, e.g. the IP address of the UE, the 
Call-ID, the P-CSCF do not change. Therefore in this case a re-INVITE needs to be sent to add ICS- 
control for the CS bearer. 



12.2.3 Not based on ICS 

After successful SR-VCC procedures (as described in 3GPP TS 24.008 [8]), if the SC UE is not using ICS capabilities 
and the SC UE does not apply the MSC Server assisted mid-call feature as specified in subclause 12.2.3A, the SC UE 
shall replace the most recently active PS audio session with the newly established CS voice call. 

NOTE: In the case when ICS is not supported or used and the SC UE does not apply the MSC Server assisted 
mid-call feature, only the most recently active audio call is transferred from PS to CS audio. 

If: 



the Gm reference point is retained upon PS handover; 
the SC UE is not using ICS capabilities; and 
- SR-VCC procedures (as described in 3GPP TS 24.008 [8]) have been completed; 
the SC UE shall: 



send a SIP re-INVITE request to the SCC AS as specified for media removal in subclause 13.2.1; and 
indicate in the SDP offer the full-duplex speech media as removed. 



12.2.3A Not based on ICS with MSC Server assisted mid-call feature 

After successful SR-VCC procedures (as described in 3GPP TS 24.008 [8]), if: 

1. the SC UE is not using ICS capabilities; 

2. the SC UE supports the MSC Server assisted mid-call feature; and 

3. there is at least one active PS audio session and the Contact header field received by the SC UE at the 
establishment of the active PS audio session, which has been most recently made active, includes the media 
feature-tag g.3gpp. mid-call as described in annex C. 

Editor's note: When there is no active PS audio session and the inactive PS audio sessions exist, whether the 
inactive PS audio sessions need to be transferred is EPS. 

then the SC UE shall apply the MSC Server assisted mid-call feature as follows: 

1 . if two or more active PS audio sessions exist, the SC UE shall replace the PS audio components of the two most 
recently active PS audio sessions with the newly established active and held CS voice calls, 

2. if one active PS audio session exists and one or more inactive PS audio sessions exist, the SC UE shall replace 
the PS audio components of the active PS audio session and of the most recently inactive PS audio session with 
the newly established active and held CS voice calls; 

3. if one active PS audio session exists and no inactive PS audio sessions exist, the SC UE shall replace the PS 
audio component of the active PS audio session with the newly established active CS voice call; 

Editor" s Note: It is EES how to ensure that the UE and MSC Server would use the same transaction identifiers for 
the conferencing sessions. 
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For each session, the SC UE shall proceed as specified in subclause 12.2.3. 

The SC UE shall associate the additional transferred session with CS call with transaction identifier 1 and TI flag value 
as in mobile terminated call. 

NOTE: The active session transaction identifier value is described in 3GPP TS 24.008 [8] 

12.3 sec AS 

1 2.3.1 sec AS procedures for PS to CS access transfer, SR-VCC 

The sec AS needs to distinguish between the following SIP INVITE requests to provide specific functionality for SR- 
VCC: 

SIP INVITE request routed to the SCC AS due to a STN-SR belonging to the subscribed user in the Request- 
URI. These SIP INVITE requests originate from the MSC server. In the procedures below, such requests are 
known as "SIP INVITE requests due to STN-SR". 

SIP re-INVITE request routed to the SCC AS containing one or more already existing media lines for audio 
indicate a CS bearer. In the procedures below, such requests are known as "SIP re-INVITE requests adding ICS 
control". 

- SIP re-INVITE request routed to the SCC AS containing one or more already existing media Unes for audio 
indicate the port set to "0". In the procedures below, such requests are known as "SIP re-INVITE requests for 
non-ICS control". 

When the SCC AS receives a SIP INVITE request due to STN-SR on the Target Access Leg, and the SCC AS does not 
apply MSC Server assisted mid-call feature as described in subclause 12.3.2, the SCC AS shall follow the PS-CS access 
transfer procedures specified in subclause 9.3.2 for the session with active full-duplex speech component that was most 
recently made active. However, the SCC AS does not initiate release for Source Access Leg unless after some specific 
time defined by the operator poUcy. 

If the SCC AS has sent a SIP 480 (Temporarily Unavailable) response to reject a SIP INVITE request due to STN-SR 
on the Target Access Leg: 

1) if the speech media flow to be transferred was the only media flow in the SIP dialog, the SCC AS shall release 
the remote leg as specified in 3GPP TS 24.229 [2]; or 

2) if the SIP dialog contains other media flows than the active speech flow, the SCC AS shall modify the remote leg 
and remove the speech media flow, as specified in 3GPP TS 24.229 [2]. 

When the SCC AS receives a SIP re-INVITE request for adding ICS control, the SCC AS shall follow the procedures as 
described for ICS using Gm in subclause 13.3.2. 

NOTE: When using the ICS controlled CS bearer, only one audio call can be active at a time. Nevertheless, 

several calls can be held in parallel. If the user decides to switch to another (previously held) call, the ICS 
controlled CS bearer is re-used for this call. Therefore no specific procedures for handling of held calls in 
the case of ICS controlled CS bearer are needed. 

When the SCC AS receives a SIP re-INVITE for non-ICS control, the SCC AS shall follow the media removal 
procedures as specified in subclause 13.3.1. 

Unless the MSC Server assisted mid-call feature applies, as only the most recent active audio call is transferred from PS 
to CS audio, the SCC AS all drop all other previously existing audio session from this UE and indicate them 
accordingly in the SDP Offer sent within SIP re-INVITE requests towards the remote UE. 

1 2.3.2 SCC AS procedures for PS to CS access transfer with MSC server 
assisted mid-call feature, SR-VCC 

If 
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1. the SC UE included the ICS feature tag as specified in the 3GPP TS 24.292 [4] in the Contact header during 
establishment of the session associated with the SIP INVITE request due to static STN, the SCC AS local policy 
requires delaying application of the MSC Server assisted mid-call feature for a time given by local policy and the 
inactive session transfer request has not been received within a time given by local policy after the reception of 
the SIP INVITE request due to static STN; 

2. the SC UE included the ICS feature tag as specified in the 3GPP TS 24.292 [4] in the Contact header during 
establishment of the session associated with the SIP INVITE request due to static STN and the SCC AS local 
policy does not require delaying application of the MSC Server assisted mid-call feature for a time given by 

local policy; or 

3. the SC UE did not include the ICS feature tag as specified in the 3GPP TS 24.292 [4] in the Contact header 
during establishment of the session associated with the SIP INVITE request due to static STN; 

then SCC AS shall apply the MSC Server assisted mid-call feature as described in subclause 9.3 .2A with the following 
differences: 

1. the SCC AS shall release all the superfluous audio sessions; and 

2. the SCC AS does not initiate release for Source Access Leg of the associated SIP dialogs but remove speech 
media flow for these dialogs. 

Removing speech media flow for SIP dialogs, the SCC AS shall: 

- if the speech media flow was the only media flow in the SIP dialogs, the SCC AS shall release the source access 
leg as specified in 3GPP TS 24.229 [2]; or 

if the SIP dialogs contains other media flows than the speech flow, the SCC AS shall modify the source access 
leg and remove the speech media flow, as specified in 3GPP TS 24.229 [2]. 

1 2.4 MSC server enhanced for ICS 

If the MSC server supports MSC Server assisted mid-call services feature, the MSC server shall be an MSC server 
enhanced for ICS as specified in 3GPP TS 29.292 [18] and 3GPP TS 24.292 [4] with following modifications: 

- associate the SIP INVITE request for an additional inactive session with CS call with transaction identifier 1 and 
TI flag value as in mobile terminated call; and 

NOTE: The active session transaction identifier value is described in 3GPP TS 24.008 [8] 

- apply procedures as described in subclause 9.4. 

12.5 EATF 

1 2.5.1 EATF procedures for PS to CS session continuity, E-SR-VCC 

The EATF needs to distinguish between the following SIP INVITE requests to provide specific fiinctionality for E-SR- 
VCC: 

1 . SIP INVITE request routed to the EATF due to E-STN-SR in the Request-URI. In the procedures below, such 
requests are known as "SIP INVITE requests due to E-STN-SR". 

NOTE: The same E-STN-SR is used for all the emergency session access transfers within one PLMN. 

When the EATF receives a SIP INVITE request due to E-STN-SR on the Target Access Leg, the EATF shall: 

1. associate the SIP INVITE request due to E-STN-SR with a source access leg, i.e. an existing SIP session 
anchored at the EATF with the instance-id feature tag provided by the SC UE in the Contact header field at 
session establishment equal to the instance-id feature tag included in the Contact header field of the received SIP 
INVITE request. If no source access leg exists or if multiple source access legs exist, then the EATF shall send a 
SIP 480 (Temporarily Unavailable) response to reject the SIP INVITE request due to E-STN-SR; and 
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2. originate session modification as described for routeing B2BUA in 3GPP TS 24.229 [2] towards the remote UE 
with a new SDP offer with media characteristics as received in the SIP INVITE request due to E-STN-SR. 

Upon receiving the SIP ACK request from the Target Access Leg, the EATF shall release the source access leg as 
described for routeing B2BUA in 3GPP TS 24.229 [2]. 

Editor's note: it is FES whether EATF needs to fulfill all the functionality of the routeing B2BUA or whether a new 
role needs to be defined for EATF in 24.229 



1 3 Roles for media adding/deleting for access transfer 

13.1 Introduction 

This clause specifies the procedures for adding or deleting media to an existing multimedia session. Procedures are 
specified for the SC UE and the SCC AS. 

13.2 SCUE 

1 3.2.1 Adding or removing media tinrougin Gm 

If the SC UE wants to add or remove media components to a session that was previously established using Gm 
reference point, the SC UE shall follow the procedures defined in 3GPP TS 24.229 [2] for adding/removing PS media. 

If the SC UE wants to transfer media components from the source access leg to an existing target access leg (i.e the 
access legs were previously established due to the partial session transfer) using Gm reference point, the SC UE shall: 

1. add the media components to the target access leg; and 

2. remove those media components from the source access leg, 

by using procedures defined in 3GPP TS 24.229 [2] for adding/removing PS media. 

If IMS service continuity using ICS is enabled then if the SC UE wants to add or remove CS media components to a 
session, it shall follow the procedures defined in 3GPP TS 24.292 [4]. 

If the SC UE receives a SIP re-INVITE request or a SIP UPDATE request from the remote end to add or remove media 
components to a session that was previously established using Gm, the SC UE shall follow the procedures defined in 
3GPP TS 24.229 [2] for adding or removing PS media and shall follow the procedures defined in 3GPP TS 24.292 [4] 
for adding or removing CS media to the session. 

1 3.2.2 Adding Gm control to existing CS session 

The SC UE shall add Gm control to an existing CS session only when there is a single full-duplex speech session over 
CS. If there is more than one full-duplex speech session, the SC UE shall release all the ongoing sessions that are not 
currently active before attempting the procedures described in this section. 

If the SC UE wants to add Gm control to an existing CS session that was established without Gm, after registering with 
the IM CN subsystem, the SC UE shall send an initial SIP INVITE request over the PS access in accordance with 
3GPP TS 24.229 [2]. The SC UE shall populate the SIP INVITE request as follows: 

set the Request-URI to the static STI; and 

set the SDP payload, in accordance with the procedures defined in 3GPP TS 24.292 [4], proposing an audio 
stream over a circuit switched bearer. The SC UE can optionally include additional PS media to the SDP in 
accordance to the procedures defined in 3GPP TS 24.229 [2]. 

Upon receiving a SIP 200 (OK) response, the SC UE shall treat the ongoing CS call as established using Gm and shall 
follow the "ICS UE using Gm" procedures defined in 3GPP TS 24.292 [4] for controlling the CS call. 
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If the SC UE receives a new SIP INVITE request containing an audio stream over a circuit-switched bearer in the SDP 
and the PSI DN matches the B-party number of the ongoing CS call that was established without Gm, the SC UE shall: 

respond to the SIP INVITE request in accordance with the procedures defined in 3GPP TS 24.292 [4]; and 

- treat the ongoing CS call as established using Gm and shall follow the "ICS UE using Gm" procedures defined in 
3GPP TS 24.292 [4] for controlling the CS call. 

13.3 sec AS 

1 3.3.1 Adding or removing media through Gm 

If the sec AS receives a SIP re-INVITE request or a SIP UPDATE request from the SC UE, in which already existing 
media components of the session are transferred from a source access leg to an already existing target access leg (i.e. 
the target access leg was already established due to partial session transfer), the SCC AS shall update the remote end 
using the session transfer procedures defined in subclause 10.3.2. 

NOTE: The SC UE indicates that media is switched from the source access leg to the target access leg by using the 
procedures defined in 3GPP TS 24.229 [2] for adding / removing PS media, i.e. the related connection and port 
information of the transferred media component within the SDP is changed from the source access leg to the target 
access leg. 

If the SCC AS receives a SIP re-INVITE request or a SIP UPDATE request from the SC UE or remote end to 
add/remove new media components, to an existing access leg of the session established using Gm, the SCC AS shall 
foUow the procedures defined in 3GPP TS 24.229 [2] for adding or removing PS media and shall follow the procedures 
defined in 3GPP TS 24.292 [4] for adding or removing CS media to the session. 

1 3.3.2 Adding Gm control to existing CS session 

If the SCC AS receives a SIP INVITE request containing the static STI in the Request-URI the SCC AS shall determine 
if this SIP INVITE request is for an ongoing call by determining if the received contents of SIP INVITE request's 
Contact header field is bound to an ongoing CS call session identifier. If the SC UE has an ongoing CS call, the SCC 
AS shall: 

- respond to the SIP INVITE request in accordance with the procedures defined in 3GPP TS 24.292 [4]; 

- treat the ongoing CS call as established using Gm and shall follow the "SCC AS for service control over Gm" 
procedures defined in 3GPP TS 24.292 [4] for controlling the CS call; and 

- if the SIP INVITE request contains additional PS media, the SCC AS shall send a SIP re-INVITE request 
towards the remote end, including the newly added PS media, in accordance with the procedures defined in 
3GPP TS 24.229 [2J. 

The SCC AS shall add Gm control to an existing CS session only when there is a single full-duplex speech session over 
CS. If the SCC AS wants to add Gm control to an existing CS session that was established without Gm, the SCC AS 
shall send a new SIP INVITE request over the PS access in accordance with 3GPP TS 24.229 [2]. The SCC AS shall 
populate the SIP INVITE request as follows: 

set the Request-URI to the public user identity of the UE; and 

- set the SDP payload, in accordance with the procedures defined in 3GPP TS 24.292 [4], proposing an audio 
stream over a circuit switched bearer. 

Upon receiving a SIP 200 (OK) response, the SCC AS shall treat the ongoing CS call as established using Gm and shall 
follow the "SCC AS for service control over Gm" procedures defined in 3GPP TS 24.292 [4] for controlling the CS 
call. 
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1 4 Roles for UE discovery for inter-UE transfer 
14.1 Introduction 

This clause specifies the target UE discovery procedures for UEs that are candidate UEs for inter UE transfer. The Hst 
of candidate UEs is a contact Hst such as name of the UE, which is represented in SIP through the use of SIP contact or 
the instance-id. The subscription of candidate UEs may be configured such that the private user identities associated 
with the UEs involved in inter UE transfer share the same set of implicitly registered public user identities. 



14.2 SCUE 

The target UE discovery procedures include the registration status (active, inactive), and the UE capabilities (e.g. 
support of audio/video formats etc.). 

In order to determine a list of UEs sharing the same set of implicitly registered public user identities and their capability 
information, the SC UE subscribes to the reg-event package as described in 3GPP TS 24.229 [2] in subclause 5.1.1.3. 

NOTE I: In order to allow inter UE transfer to UEs belonging to the same subscription but belonging to a different 
set of implicitly registered public user identities, a user can have a static list of UEs that is manually 
administered by the user and stored locally in the user's device (e.g. phone book). Having a static list is an 
implementation in the UE and has no impact on the standards. 

NOTE 2: If the UE is not part of the same set of implicitly registered public user identities as the SC UE, or if the 
SC UE was unable to obtain the capabiHty information of the UE through the use of reg-event package, 
the SC UE can send a SIP OPTIONS request to the UE to attempt to retrieve capability information. In 
order to avoid a lot of transactions, a SIP OPTIONS request is generated based on an action initiated by 
the user (e.g. after the user has finished adding a new UE in the static list, or the user explicitly asks for 
getting UE capability information). 



14.3 sec AS 

The information of UEs that belong to the same subscription is required at the SCC AS for the purpose of authorizing 
that the requested inter UE transfer to the UE is allowed, i.e. to prevent the SC UE from performing Inter UE Transfer 
to a UE under a different subscription. 

The SCC AS obtains all the public user identities associated with the user's subscription from the Sh interface as 
specified in 3GPP TS 29.328 [6] and 3GPP TS 29.329 [7]. 

NOTE 1 : Getting the public user identities over the Sh interface allows the SCC AS to receive information of UEs 
sharing the same set of implicitly registered public user identities and information of UEs within the same 
subscription that are not in the same set of implicitly registered public user identities. This is needed to 
authorize the static list of UEs that is manually administered by the user and stored locally in the user's 
device. 



The SCC AS can obtain the registration information (e.g. GRUU) by the following methods: 

1. using the 3rd party REGISTER request as described in 3GPP TS 24.229 [2] in subclause 5.4.1.7; or 

2. the SCC AS subscribes to the reg-event package as described in 3GPP TS 24.229 [2] in subclause 5.4.2.1.1. 

NOTE 2: The SCC AS needs to know the public user identity for the authorization of the SIP REFER request for 
inter UE transfer. To get the public user identity from the public GRUU, the SCC AS can simply remove 
the "gr" parameter from the public GRUU. Using the 3rd-party registration or subscribing to the reg-event 
package allows the SCC AS to find the temporary GRUU of the UE and to correlate the GRUU with the 
public user identities. After correlation, the SCC AS would make a hst of GRUUs that are associated with 
the same subscription and/or with the same set of implicitly registered public user identities. 
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1 5 Roles for inter-UE transfer without establishment of 
collaborative session 

15.1 Introduction 

This clause specifies the procedures for transferring all media of an existing session from one UE to another UE of the 
same user. Procedures are specified for the transferor SC UE, the transferee SC UE and the SCC AS. 

Editor's note: the solution needs to ensure that the requests are routed via the SCC AS 

15.2 SCUE 

15.2.1 Transferor SC UE in services defining only originating session set 
up in UE 

In order to transfer all media of an existing session from this UE to another UE of the same user, the SC UE shall send a 
SIP REFER request as specified in IETF RFC 3515 [13] and in accordance with UE procedures specified in 
3GPP TS 24.229 [2]. The SC UE shall populate the SIP REFER request as follows: 

1. the Request-URI set to the GRUU of the UE where the session is to be transferred to; 

2. the Refer-To header field set to the URI contained in the Contact header field returned at the creation of the 
dialog and extended with the following URI header fields: 

A. if usage of SIP Replaces extension is selected: 

a. the Replaces header field populated as specified in IETF RFC 3891 [10], containing the dialog identifier 
of the Access Leg between this UE and the SCC AS; and 

b. the Require header field populated with the option tag value "replaces"; 

B. if usage of SIP Target-Dialog extension is selected: 

a. the Target-Dialog header field populated as specified in IETF RFC 4538 [11], containing the dialog 
identifier of the Access Leg between this UE and the SCC AS; and 

b. the Require header field populated with the option tag value "tdialog"; and 

C. if the session is established using an IMS communication service that requires the use of an IMS 
communication service identifier: 

a. Accept-Contact header field with the g.3gpp.icsi-ref media feature tag containing the IMS communication 
service identifier of the existing session; and 

b. P-Preferred-Service header field set to the IMS communication service identifier of the existing session. 

3. include in the Contact header field: 

A. a public GRUU or temporary GRUU as specified in 3GPP TS 24.229 [2]. 

If the SC UE receives any SIP 4xx - 6xx response to the SIP REFER request or if the SC UE receives a SIP NOTIFY 
request containing a message/sipfrag body with SIP 4xx - 6xx response, then the inter UE transfer has not completed 
successfully. 

1 5.2.2 Transferee SC UE in services defining only originating session set 
up in UE 

Upon receiving a SIP REFER request with P-Asserted-Identity containing the URI of the served user, the SC UE shall 
send a SIP INVITE request in accordance with UE procedures specified in 3GPP TS 24.229 [2] and 
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IETF RFC 3515 [13]. The SC UE shall populate the SIP INVITE request with header fields which were included as 
URI header fields in the URJ in the Refer-To header field of the received SIP REFER request. 

15.3 sec AS 

1 5.3.1 Distinction of requests sent to the SCC AS 

The SCC AS needs to distinguish between the following SIP requests to provide specific fimctionaUty relating to inter 
UE transfer: 

1 . SIP INVITE request routed to the SCC AS upon originating filter criteria containing a STI belonging to the 
subscribed user in: 

A. the Target-Dialog header field; or 

B. in the Replaces header field 

with at least one offered media used in session by a UE other than the UE identified by the Contact header field 
value. In the procedures below, such request is known as "SIP INVITE request due to inter UE transfer". 

2. SIP REFER request routed to the SCC AS due to the originating filter criteria where 

A. the GRUU in the Contact header field identifies a UE of the user identified in P-Asserted-Identity header 
field; 

B. the GRUU in the Contact header field identifies a UE of the same user as the GRUU in the Request-URI; 

and, 

C. the dialog identifier in: 

a. the Replaces URI header field of the URI in the Refer-To header field; or 

b. the Target-Dialog URI header field of the URI in the Refer-To header field 
belongs to a session of the UE identified by the GRUU in the Contact header field. 

In the procedures below, such request is known as "SIP REFER request due to inter UE transfer". 

Other SIP initial requests for a dialog and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [2]. 

15.3.2 Inter UE transfer request authorization in services defining only 
originating session set up in UE 

Upon receiving a SIP REFER requests due to inter UE transfer, the SCC AS shall: 

1. reject the SIP request with a SIP 403 (Forbidden) response and do not process the remaining steps if 

A. media of the session one leg of which is identified by the dialog identifier in 

a. the Replaces URI header field of the URI in the Refer-To header field; or 

b. the Target-Dialog URI header field of the URI in the Refer-To header field; 
are delivered to two or more UEs of the user; or 

B. at least one media of the session identified by the dialog identifier in 

a. the Replaces URI header field of the URI in the Refer-To header field; or 

b. the Target-Dialog URI header field of the URI in the Refer-To header field 

is deUvered to a UE other than the UE identified by the GRUU in the Contact header field; 



ETSI 



3GPP TS 24.237 version 9.1 .0 Release 9 



43 



ETSI TS 124 237 V9.1.0 (2010-01) 



2. insert a Record-Route header field with SCC AS own address; and 

3. forward the SIP REFER request in any manner conformant with 3GPP TS 24.229 [2]. 

The SCC AS shall forward the SIP response to the SIP REFER request, the SIP NOTIFY request, and the SIP response 
to the NOTIFY request in any manner conformant with 3GPP TS 24.229 [2]. 

15.3.3 SCC AS procedures for inter UE transfer in services defining only 
originating session set up in UE 

Upon receiving a SIP INVITE request due to inter UE transfer, the SCC AS shall: 

1. reject the SIP request with a SIP 403 (Forbidden) response and do not process the remaining steps if 

A. the SCC AS is not aware of a subscription created by a SIP REFER request with the dialog identifiers 

a. in the Replaces header field of the received SIP INVITE and in the Replaces URI header field of the URI 
in the Refer-To header field of the SIP REFER request are equal; or 

b. in the Target-Dialog header field of the received SIP INVITE and in the Target-Dialog URI header field 
of the URI in the Refer-To header field of the SIP REFER request are equal; 

2. associate the received SIP INVITE request with an ongoing SIP dialog by matching the dialog identifier in the 
Replaces header field or the Target-Dialog header field. By an ongoing SIP dialog, it is meant a dialog for which 
a SIP 2xx response to the initial SIP INVITE request has been sent or received; 

3. if dialog identifier is not included in either in the Replaces header field or in the Target-Dialog header field or if 
the included dialog identifier does not identify an existing ongoing dialog, send a SIP 480 (Temporarily 
Unavailable) response to reject the SIP INVITE request and not processes the remaining steps; 

4. identify the Source Access Leg by the dialog identifier present in the Replaces or the Target-Dialog header field 
of the SIP INVITE request; 

5. if a media used in the Source Access Leg session is not offered in the SDP offer of the SIP INVITE request then 
reject the SIP request with a SIP 403 (Forbidden) response and do not process the remaining steps; 

6. if the SIP INVITE request contains a Replaces header field: 

A. follow the procedures defined in IETF RFC 3891 [10] for replacing the Source Access Leg with the SIP 
request received on the Target Access Leg, including terminating the Source Access Leg by sending a SIP 
BYE towards the SC UE in accordance with 3GPP TS 24.229 [2]; and 

7. send a SIP re-lNVlTE request towards the remote UE using the existing established dialog. The SCC AS shall 
populate the SIP re-INVITE request as follows: 

A. include a new SDP offer including the media characteristics as received in the SIP INVITE request, by 
following the rules of the 3GPP TS 24.229 [2]. 

Upon receiving the SIP ACK request originated from the SC UE, the SCC AS shall initiate release of the Source Access 
Leg by sending a SIP BYE towards the SC UE in accordance with 3GPP TS 24.229 [2]. 



1 6 Roles for collaborative session establishment for 
inter-UE transfer 

16.1 Introduction 

This clause specifies the roles of controller UE, controUee UE and the SCC AS when controller UE transfers media to a 
controUee UE or adds a new media to the controUee UE. 
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16.2 SCUE 

16.2.1 SC UE procedures for collaborative session establishment by 
transferring media used in an existing session 

1 6.2.1 .1 Controller UE procedures 

To establish a collaborative session by transferring the media component, the controller UE shall send a SIP REFER 
request outside the existing dialog as specified in RFC 3515 [13] and include: 

1) the Request-URI set to the SIP URI of the SCC AS 

2) the Refer-To header field set as follows: 

a) the SIP URI of the controllee UE; 

NOTE: The SIP URI of the controllee UE needs to be a GRUU if the controllee UE and any other UEs share the 

same public user identity. 

b) the body parameter containing SDP for the media (m=) lines in the session set as follows: 

- media Unes that are not being transferred with the port number set to zero 

media line(s) that are to be transferred containing the port number for the corresponding media received 
in the media line of the SDP received during the last successful SDPoffer answer exchange; 

3) the Accept header field containing the MIME type "message/sipfrag"; and 

4) the Target-Dialog header field containing the dialog parameters for the dialog of the existing session. 

The controller UE shall handle response to the SIP REFER request and the subsequent SIP NOTIFY requests according 
to 3GPP TS 24.229 [2] and RFC 3515 [13]. The controller UE shall save the media information (e.g. media hne(s) and 
port number(s)) related to the transferred media(s) received in the sipfrag body of the SIP NOTIFY requests in order to 
perform further inter-UE transfer operations on the controllee UE. When the controller UE receives a SIP re-INVITE 
request from the SCC AS to update the status of the transferred media component after a sucusseful transfer, the 
controller UE shall follow the procedures described in 3GPP TS 24.229 [2]. 

If an error response is received for the SIP REFER request or the subsequent SIP NOTIFY requests include a non-2xx 
final response, the controller UE shall consider the transfer operation failed and continue the existing session. 

1 6.2.1 .2 Controllee UE procedures 

There are no specific procedures for the controllee UE for the collaborative session establishment by transferring media, 
besides the procedures described in 3GPP TS 24.229 [2]. 

1 6.2.2 SC UE procedures for collaborative session establishment with new 
media 

16.2.2.1 Controller UE procedures 

The controller UE may establish a collaborative session with a new media at anytime while it has an ongoing IMS 
established session according to 3GPP TS 24.229 [2] with a remote UE. 

The controller UE shall add the new media by sending a SIP REFER request outside the existing dialog as specified in 
RFC 3515 [13] and include: 

1) the Request-URI set to the SIP URI of the SCC AS; 

2) the Refer-To header field set as follows: 
a) the SIP URI of the controllee UE; 
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NOTE 1: The SIP URI of the controUee UE needs to be a GRUU if the controUee UE and other UEs share the same 
public user identity. 

b) the body parameter containing SDP for the media (m=) lines in the session shall be set as follows: 
media lines that are not being transferred with the port number set to zero 

media lines that are to be added containing the discard port number "9" for the media line(s) to be 
trans fered 

NOTE 2: The discard port number "9" indicates that this port number should be ignored. 

3) the Accept header field containing the MIME type "message/sipfrag";and 

4) the Target-Dialog header field containing the dialog parameters for the dialog of the existing session 

The controller UE shall handle response to the SIP REFER request and the subsequent SIP NOTIFY requests according 
to 3GPP TS 24.229 [2] and RFC 3515 [13]. The controller UE shall save the media information (e.g. media line(s) and 
port number(s)) received in the sipfrag body of the SIP NOTIFY requests in order to perform further inter-UE transfer 
operations on the controUee UE. 

If error response is received for the SIP REFER request or the subsequent SIP NOTIFY requests include a non-2xx final 
response, the controller UE shall consider the transfer operation failed and continue the existing session. 

16.2.2.2 ControUee UE procedures 

There are no specific procedures for the controUee UE for the collaborative session establishment by adding media, 
besides the procedures described in 3GPP TS 24.229 [2]. 

16.3 sec AS 

1 6.3.1 Distinction of requests sent to tine SCC AS 

The SCC AS needs to distinguish between the following initial SIP REFER requests to provide specific functionality 
relating to call origination: 

1) SIP REFER requests routed to the SCC AS containing: 

a) the SCC AS address in the request URI; and 

b) the Refer-To header filed including: 

the address of a UE which is neither the UE which sent the SIP REFER request, nor the remote UE, but 
which is within the list of UEs which can be involved within an collaborative session with the UE which 
originated the SIP REFER request; 

zero or more media lines which indicate the port value 0; and 

one or more media lines which indicate the discard port value 9. 

In the procedures below, such SIP REFER requests are called "SIP REFER requests for establishing new media at 
controUee UE". It is assumed that the SCC AS is the first AS that the S-CSCF forwards the request to after receiving the 
request from the UE. 

Other SIP initial requests for a dialog, and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [8]. 

Editor's Note: further types of REFER have to be determined. 
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1 6.3.2 sec AS procedures for collaborative session establishment by 
transferring media 

NOTE: If the controller UE is already involved in a collaborative session then the procedures in 
subclause 17.13.1 apply. 

Editor's Note: The text in this first line will need to be aligned with a future change request that will provide the 
procedures for determination of when to invoke this subclause. 

When the SCC AS establishes a collaborative session by transferring media as a result of receiving a SIP REFER 
request from the controller UE , the SCC AS shall send: 

1) a response to the SIP REFER request with SIP 202 (Accepted) and send a SIP NOTIFY request containing a 
sipfrag for a SIP 100 (Trying) response to the controller UE as specified in RFC 3515 [13]; and 

2) a SIP INVITE request to controUee UE, containing: 

a) Request-URI with SIP URI from the Refer-To header field of the received SIP REFER request; 

b) the Referred-By header field containing the URI from the P-Asserted-Identity header field of the received 
SIP REFER request; 

c) the P-Asserted-Identity header field containing the identity of the remote UE as received in the P-Asserted- 
Identity header field from the remote UE at the original session establishment; and 

d) the SDP information for the media component to be transferred as follows: 

The media (m=) lines from the body parameter in the Refer-To header field of the received SIP REFER 
request; and 

for media lines which have non zero port nunmbers the SDP parameters from the corresponding media 
lines as received during the last successful SDPoffer-answer exchange from the remote party 

Upon receiving a final response from the controllee UE, the SCC AS shall send, a SIP NOTIFY request containing the 
received final response code in the sipfrag body and if the received response was a SIP 200 (OK) response containing 
an SDP answer then also include in the sipfrag the Content-Type header field from the received 200 (OK) response 
along with the media (m=) lines from the SDP answer. 

If the final response was a non 2xx response then the SCC AS shall consider the transfer operation failed and abort the 
media transfer and establishment of the collaborative session. 

If the final response was a SIP 200 (OK) response containing a SDP answer, the SCC AC shall send a SIP re-INVITE 
request on the dialog for the remote leg to the remote UE as sepcified in 3GPP TS 24.229 [2]. The SCC AS shall: 

1) send a SIP re-INVITE request containing SDP information as follows: 

a) for the transferred media component(s), set the SDP information as from the SDP answer received in the SIP 
200 (OK) response from the controllee UE; 

b) for all other media components in the collaborative session, include the SDP information as from the original 
session to the remote leg. 

2) send a SIP re-INVITE request to the controller UE following the procedures described in 3GPP TS 24.229 [2] to 
remove the media for the transferred media component. 

Upon receiving a SIP 200 (OK) response with the SDP answer on the remote leg, the SCC AS shall send an ACK 
response on remote leg. 

1 6.3.3 SCC AS procedures for collaborative session establishment with 
new media 

When SCC AS receives a SIP REFER request in a new dialog from the contoUer UE for establishing a collaborative 
session by adding new media to the controllee UE, the SCC AS shall send: 
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1) SIP 202 (Accepted) response to the controller UE; 

2) SIP NOTIFY request containing a sipfrag for a SIP 100 Trying as described in RFC 3515 [13] to the controller 
UE; and 

3) SIP INVITE request in accordance to 3GPP TS 24.229 [2] to the controllee UE. The SCC AS shall construct the 
SIP INVITE request as follows: 

Request-URI set to the SIP URI from the Refer-To header field of the received SIP REFER request; 

includes an SDP offer and sets all the m-lines to zero except the m-line of the media component is to be 
added as the last m-line in the SDP; and 

if the m-line in the received SDP of the SIP REFER request is set to the discard port number "9", the SCC 
AS shall include an a-line set to inactive in the SDP offer. 

Editor's note: The value of c-line is EES. 

If non-2xx final response is received from the controllee UE, the SCC AS shall send a SIP NOTIFY request including 
the final response as sipfrag body to the controller UE and consider the inter-UE transfer operation failed. Otherwise, 
the SCC AS continues with the remainder of the steps described in this subclause. 

Upon receiving a response from the controllee UE with a SDP answer, the SCC AS shall send a SIP re-INVITE request 
to the remote UE as specified in 3GPP TS 24.229 [2]. The SCC AS shall construct the SDP offer in the SIP re-INVITE 
request as follows: 

1) Request-URI with SIP URI from the Refer-To header field of the received SIP REFER request; 

2) the Referred-By header field containing the URI from the P-Asserted-Identity header field of the received SIP 
REFER request; 

3) the P-Asserted-Identity header field containing the identity of the remote UE as received in the P-Asserted- 
Identity header field from the remote UE at the original session establishment; and 

4) the SDP information from the body parameter in the Refer-To header field of the received SIP REFER request 
and for media lines which have non zero port nunmbers the SDP parameters forthe corresponding media lines as 
received during the last successful SDPoffer-answer exchange with the remote party. 

Upon receiving a final response from the controllee UE, the SCC AS shall send, a SIP NOTIFY request containing the 
received final response code in the sipfrag body and if the received response was a SIP 200 (OK) response containing a 
SDP answer then also include in the sipfrag the Content-Type header field from the received 200 (OK) response along 
with the media (m=) lines from the SDP answer. 

If the final response was a non 2xx response then the SCC AS shall consider the transfer operation failed and abort the 
media transfer and establishment of the collaborative session. 

If the final response from the remote UE was a SIP 200 (OK) response with the SDP answer, the SCC AS shall: 

1) send to the remote UE a SIP ACK request; and 

2) send to the controllee UE: 

if Allow header in the received SIP 200 (OK) response indicates the controllee UE support the SIP 
UPDATE request, a SIP UPDATE request containing the current port number for the media component to be 
added; otherwise 

a SIP re-INVITE request containing the current port number for the media component to be added. 

NOTE: Any other changes such as IP address of the remote leg in case remote leg uses different IP addresses for 
different media components can also be updated in the SIP UPDATE request or SIP re-INVITE request. 

Upon successful completion of the SDP offer answer exchange using SIP re-INVITE request with the controlee UE, the 
SCC AS shall: 

1) send to the controllee UE a SIP ACK request 
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Editor's note: This is FFS how to inform the controller UE about current port number of the remote UE or any other 
changes such as IP address. 

1 6.3.4 Procedures to indicate SCC AS establisliing a collaborative session 
by adding a new media 

When SCC AS receives a SIP REFER request in a new dialog from the contoller UE with; 

1) the Request-URI parameter set to SIP URI of the SCC AS; and 

2) the Refer-To header set to GRUU of a controllee UE and URI parameter containing SDP listing; 

all the media components with associated information in the session; and 

a new media component with associated port number set to the discard port number "9" as the last media 
component, 

the SCC AS shall follow the procedure in subclause 16.3.2 to establish a collaborative session with the controllee UE. 
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1 8.2.2 Procedures for collaborative session release by remote party 

18.2.2.1 Controller UE 

18.2.2.2 ControlleeUE 

18.3 sec AS 

18.3.1 Procedures for collaborative session release by controller UE 

1 8.3.2 Procedures for collaborative session release by remote party 

1 9 Roles for media adding/deleting within collaborative 
session for inter-UE transfer 

19.1 Introduction 

19.2 SCUE 

1 9.2.1 Procedures for adding new media on controllee UE by controller UE 

19.2.2 Procedures for releasing media on controllee UE by controller UE 

The controller UE may release a media component on a controllee UE within a collaborative session while it has an 
ongoing IMS session with a remote UE. 

The controller UE shall release the media by sending a SIP REFER request for releasing media component, including: 

1) the Request-URI set to the SIP URI of the SCC AS; 

Editor's note: This is FFS how to obtain the SIP URI of the SCC AS. 

2) the Refer-To header as follows: 

a) the SIP URI of the controllee UE; 

NOTE: The SIP URI of the controllee UE needs to be a GRUU if the controllee UE and any other UEs share the 
same public user identity. 

b) the body parameter containing SDP for the media (m=) lines in the session shall be set as follows: 

media lines that are not being released with their port numbers; and 
- media hne(s) that are to be released with the port number set to zero; 

3) the Accept header field set to "message/sipfiag"; and 

4) the Target-Dialog header field populated as specified in IETF RFC 4538 [11], containing the dialog identifier of 

the collaborative session. 

The controller UE shall handle response to the SIP REFER request and the subsequent SIP NOTIFY requests according 
to 3GPP TS 24.229 [2]. If the media component to be removed is not the last media component on the controllee UE, 
the controller UE shall save the media information (e.g. media line number) received in the sipfrag body of the SIP 
NOTIFY request in order to perform further inter-UE transfer operations on the controllee UE. 
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19.2.2A Procedures for releasing media on controller UE by controller UE 

If the controller UE wants to release a media component on the controller UE within a collaborative session, the 
controller UE shall follow the procedures defined in 3GPP TS 24.229 [2] for removing media with the following 

differences: 

1. include the SDP information for all other media components within the collaborative session in the SIP re- 
INVITE request;and 

2. set all the ports number of the media on the controllee UEs with value zero. 



1 9.2.3 Procedures for releasing media by controlee UE 



1 9.2.3.1 Media flow on controller UE 



1 9.2.3.2 Media flow on controllee UE 



19.2.4 Procedures for modifying media on controllee UE by itself 

If the controllee UE wants to modify the characteristics of a media component on itself within a collaborative session, 
the controllee UE shall follow the procedures defined in 3GPP TS 24.229 [2] for modifying media. 



1 9.2.5 Procedures for adding new media by remote party when the 
controller UE does not alert the user 

When controller UE receives a SIP re-INVITE request within an existing dialog from the remote UE to add a new 
media component on the collaborative session, the controller UE shall decide whether adding the new media on itself or 
adding it to one of its controllee UE. 

If the controller UE decides to add the new media component on itself, the controller UE shall follow the precedure as 
specified in 3GPP TS 24.229 [2], 

If the controller UE decides to add the new media component on one of its controllee UE, the controller UE shall send a 
SIP REFER request outside the existing dialog as specified in RFC 3515 [13] and include: 

1) the Request-URl set to the SIP URI of the SCC AS; 

2) the Refer-To header, including: 

a) the SIP URI of the controllee UE where the media stream should be estabUshed from; and 

NOTE: The SIP URI of the controllee UE needs to be a GRUU if the controllee UE and any other UEs share the 
same public user identity. 

b) the body parameter containing SDP for the media (m=) lines for the media Unes in the session shall be set as 

follows: 

media lines that are not being transferred with the port number set to zero; 

- media Une(s) that are to be added at the controllee UE the same SDP information as in the SIP re-INVITE 
request received from the remote party. 

3) the Accept header field containing the MIME types "message/sipfrag";and 

4) the Target-Dialog header field containing the dialog parameters for the dialog of the existing session 

The controller UE shall handle response to the SIP REFER request and the subsequent SIP NOTIFY requests according 
to 3GPP TS 24.229 [2]. Then the controller UE shall response the SIP re-INVITE request with a SIP 200 (OK) response 
with a SDP answer as specified in 3GPP TS 24.229[2], and construct the SDP information in the SIP 200 (OK) 
response as follows: 

1) set the port number of the new added media component with value zero; and 



ETSI 



3GPP TS 24.237 version 9.1 .0 Release 9 



52 



ETSI TS 124 237 V9.1.0 (2010-01) 



2) set all the ports number of the media on the controllee UEs with value zero; and 

3) for other media components on the controller UE are not changed. 

If an error response is received for the SIP REFER request or the subsequent SIP NOTIFY requests include a non-2xx 
final response, the controller UE shall consider the transfer operation failed and make a decision again whether adding 
the new media on itself or adding it on other controllee UE. 

1 9.2.6 Procedures for releasing media by remote party 

19.3 sec AS 

19.3.1 Procedures for adding new media on controllee UE by controller UE 

1 9.3.2 Procedures for releasing media on controllee UE by controller UE 

Editor's Note: It is FFS how to ensure that ICMP messages are not generated due to media sent to closed port. 

When sec AS receives a SIP REFER request in a new dialog from the controller UE to remove a media component on 
a controllee UE, the SCC AS shall send: 

1) SIP REFER request with SIP 202 (Accepted) response to the controller UE; 

2) SIP NOTIFY request with sipfrag including SIP 100 Trying to the controller UE; 

3) if the media component is the only active media component on the target controllee UE, send a SIP BYE request 
to the controllee UE to release the controlled session based 3GPP TS 24.229 [2]; and 

4) if the media component is not the last active media component on the target controllee UE, send a SIP re- 
INVITE request to the controllee UE, containing an SDP offer where the media component to be removed is set 
to port number zero while the media information for other media components are not changed. 

Upon receiving SIP 200 (OK) response from the controllee UE, the SCC AC shall send a SIP re-INVITE request to the 
remote leg as specified in 3GPP TS 24.229 [2]. The SCC AS shall construct the SDP information in the SIP re-INVITE 
request as follows: 

1) set port number for removed media component to zero; and 

2) include the SDP information for all other media in the collaborative session as from the original session to the 
remote leg. 

Upon receiving SIP 200 (OK) response with the SDP answer from the remote leg, the SCC AS shall send: 

1) a SIP ACK request to the remote leg; 

2) upon successful release of the media component, a SIP NOTIFY request to the controller UE: 

If the SCC AS has released the session toward the controllee UE due to removal of the last media component, 
the sipfrag body shall include the SIP 200 (OK) response of the SIP BYE request; and 

If the session between the controllee UE and the SCC AS still exists due to existence of other media 
components, the sipfrag body shall include the SIP 200 (OK) response of the SIP re-INVITE request and also 
include the SDP information received from the controllee UE. 

1 9.3.2.1 Distinction of requests at the SCC AS 

When SCC AS receives a SIP REFER request in a new dialog from the contoller UE with: 

1) the Request-URI parameter set to SIP URI of the SCC AS; and 

2) the Refer-To header set to SIP URI of a controllee UE and URI parameter containing SDP listing: 
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- all the media components with associated information in the session; and 

- the media component is to be released with associated port number set to 0. 

the sec AS shall follow the procedure in subclause 19.3.2 to release the media component from the controUee UE. 

19.3.2A Procedures for releasing media on controller UE by controller UE 

When sec AS receives a SIP re-INVITE request within an existing dialog from the controller UE to remove a media 

component on itself, the SCC AS shall send a SIP re-INVITE request to the remote UE as specified in 

3GPP TS 24.229[2]. The SCC AS shall construct the SDP information in the SIP re-EWITE request as follows: 

1) set port number for the removed media component to zero; and 

2) include the SDP information for all other media in the collaborative session as received during the last successful 
SDP offer-answer exchange from the remote party. 

Upon receiving SIP 200 (OK) response with the SDP answer from the remote UE, the SCC AS shall send: 

1) a SIP ACK request to the remote UE; 

2) a SIP 200 (OK) response to the controller UE as specified in 3GPP TS 24.229[2]. The SCC AS shall construct 
the SDP infromation in the SIP 200 (OK) response as follows: 

- set port number for the removed media component to zero; and 

- set all the ports number of the media on the controllee UEs with value zero. 

1 9.3.3 Procedures for releasing media by controlee UE 

1 9.3.3.1 Media flow on controller UE 

1 9.3.3.2 Media flow on controllee UE 

19.3.4 Procedures for modifying media on controllee UE by itself 

When SCC AS receives a SIP re-INVITE request within an existing dialog from the controllee UE to modify a media 

component on itself, the SCC AS shall send a SIP re-INVITE request to the remote UE as specified in 

3GPP TS 24.229 [2]. The SCC AS shall construct the SDP information in the SIP re-INVITE request as follows: 

1) set the modified media information as the same in the SIP re-INVITE request received from the controllee UE; 
and 

2) include the SDP information for all other media in the collaborative session as received during the last successful 
SDP offer-answer exchange from the remote party. 

Upon receiving SIP 200 (OK) response with the SDP answer from the remote UE, the SCC AS shall send: 

1) a SIP ACK request to the remote UE; and 

2) a SIP 200 (OK) response to the controllee UE with the SDP answer only contains the media component on the 
controllee UE. 

1 9.3.5 Procedures for adding new media by remote party when the 
controller UE does not alert the user 

When SCC AS receives a SIP REFER request from the controller UE to add a new media component on a controllee 
UE, the SCC AS shall send: 

1) a response to the SIP REFER request with SIP 202 (Accepted) response and send the SIP NOTIFY request 
containing a sipfig for a SIP 100 (Trying) response to the controller UE as described in RFC 3515 [13]; 
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2) if the target controllee UE has not been involved in the collaborative session, send a initial SIP INVITE request 
to the controllee UE to add the controlee UE in the collaborative session, containing: 

a) Request-URI with SIP URI from the Refer-To header field of the received SIP REFER request; 

b) the Referred-By header field containing the URI from the P-Asserted-Identity header field of the received 
SIP REFER request; 

c) the P-Asserted-Identity header field containing the identity of the remote UE as received in the P-Asserted- 
Identity header field from SIP re-INVITE request received from the remote UE; and 

d) the SDP information for the media component to be transferred as follows: 

- The media (m=) lines from the body parameter in the Refer-To header field of the received SIP REFER 
request; and 

- for media lines which have non zero port nurmibers the SDP parameters from the corresponding media 
lines as received in the SDP offer from the remote party in the SIP re-INVITE request. 

3) if there are other media component within the collaborative session between the target controllee UE and the 
remote UE, send a SIP re-INVITE request to the controllee UE, containing: 

a) the SDP information for the media component to be transferred as follows: 

The media (m=) lines from the body parameter in the Refer-To header field of the received SIP REFER 
request; and 

- for media lines which have non zero port nunmbers the SDP parameters from the corresponding media 
lines as received in the SDP offer from the remote party in the SIP re-INVITE request 

for other media components that have already involved in the coUabartive session are not changed. 

Upon receiving a final response from the controllee UE, the SCC AS shall send, a SIP NOTIFY request containing the 
received final response code in the sipfrag body and if the received response was a SIP 200 (OK) response containing 
an SDP answer then also include in the sipfrag the Content-Type header field from the received 200 (OK) response 
along with the media (m=) lines from the SDP answer. 

If the final response was a non 2xx response then the SCC AS shall consider the transfer operation failed and abort the 
media transfer. 



If the final response was a SIP 200 (OK) response containing a SDP answer, the SCC AS shall: 

1) send a SIP ACK request to the controllee UE; 

2) send a SIP 200 (OK) response to the remote UE as specified in 3GPP TS 24.229 [2]. The SCC AS shall 
construct the SDP infromation in the SIP 200 (OK) response as follows: 

- set the same SDP information for the new added media as in the SIP 200 (OK) response received from the 
controlee UE; and 

- include the SDP information for all other media in the collaborative session as received during the last 
successful SDP offer-answer exchange from the remote party. 
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1 9.3.6 Procedures for releasing media by remote party 
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Annex A (informative): 
Example signalling flows 

A.1 Scope of signalling flows 

This annex gives examples of signalling flows for Service Continuity based on the Session Initiation Protocol (SIP) and 

SIP Events. 

These signalhng flows provide detailed signalhng flows, which expand on the overview information flows provided in 
3GPPTS 23.237 [9]. 

A.2 Introduction 
A.2.1 General 

The signalhng flows provided in this annex follow the methodology developed in 3GPP TS 24.228 [3]. 

A.2. 2 Key required to interpret signalling flows 

The key to interpret signalling flows specified in 3GPP TS 24.228 [3] subclauses 4.1 and 4.2 applies with the additions 
specified below: 

- tel:+l-237-555-llll represents the public user indentity of SC UE A. 

- tel:+l-237-555-2222 represents the public user indentity of UE B. 

- sip:sccasl.homel.net represents the Internet host of SCC AS. 

Each signalling flow table contains descriptions for headers where the content of the header is new to that signalling 
flow, as is already performed in 3GPP TS 24.228 [3]. 

However, 3GPP TS 24.228 [3] includes extensive descriptions for the contents of various headers following each of the 
tables representing the contents of the signalling flows. Where the operation of the header is identical to that shown in 
3GPP TS 24.228 [3], then such text is not reproduced in the present document. 

Additional text may also be found on the contents of headers within 3GPP TS 24.228 [3] in addition to the material 
shown in the present document. 

In order to differentiate between messages for SIP and media, the notation in figure A.2-1 is used. 

INVITE 

► SIP message 



SETUP 

► CS message 



Media over a PS connection 



Media over a CS connection 



Figure A.2-1 : Signalling flow notation 
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A.3 Signalling flows for registration 
A.3.1 Introduction 

When using CS access for media and to make use of the IMS ISC procedures, the SC UE is registered in IM CN 
subsystem and the signalling flows are defined in 3GPP TS 24.292 [4] subclause A.2. 

When initiating a CS call, the SC UE can be registered in the CS domain as defined in 3GPP TS 24.008 [8]. 

Whenever the UE acquires IP connectivity via an IP-CAN, the signalling flows for registration in the IMS are defined 
in 3GPP TS 24.228 [3]. 



A.3. 2 Signalling flows for multiple registration for service 
continuity 

The signalling flows shown in figure A. 3. 2-1 gives an example when a UE connects to different IP-CAN respectively 
and performs multiple registrations. In this example the SCC AS receives the registration state information that it needs 
to implement SCC specific requirements from the third-party REGISTER request. 



UE 



— 1. SIP Register#l- 



P-CSCF#1 



-6. 200 OK- 



9.UE connects to a 
new IP-CAN 



P-CSCF#2 





I-CSCF 
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Register#l 
-4. 200 OK- 
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Register#2 
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-7. SIP Registei^ 
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-22. SIP Registei*- 
^23. 200 OK- 



Figure A.3.2-1 Signalling flows for multiple registrations 

1. SIP REGISTER request (UE to P-CSCF#1)-See example in table A.3.2-1 

UE sends the SIP REGISTER request via the IP-CAN#1. 
NOTE 1: For clarity, the unprotected SIP REGISTER request via the IP-CAN#1 is not shown in this example. 
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Table A.3.2-1SIP REGISTER request (UE to P-CSCF#1) 



REGISTER sip: registrar. homel.net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max-Forwards: 70 

P-Access-Network-Info : 3GPP-UTRAN-TDD ; utran-cell-id-3gpp=234151D0FCEll 
From : <sip : userl_publicl@homel . net > ; tag=4f a3 
To : <sip : userl_publicl@homel . net > 

Contact: <sip: [5555 :: aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp> ; reg-id=l; +sip . instance= " < 
urn : gsma : imei :90420156-025763-0 >";+g. 3gpp .icsi-ref= "urn%3Aurn- 7%3gpp- 

service . ims . icsi . mmtel " ; +g . 3gpp . ics= "principal " ; +g . 3gpp . access type= " cellularl " ; expires=6000 
00 

Call -ID : apb03a0s09dkjdfglkj4 9111 

Authorization: Digest username= "userl_private@homel . net " , realm= " registrar . homel . net " , 
nonce=base64 (RAND + AUTN + server specific data), algorithm=AKAvl -MD5 , 
uri=" sip: registrar .homel .net" , response= " 662 9f ae493 93a053 97450978507c4ef 1 " 

Security-Client: ipsec-3gpp; alg=hmac-sha-l-96 ; spi-c=23456789 ; spi-s=12345678 ; port-c=2468; 
port-s=1357 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c = 98765432 ; spi -s =8765432 1 ; port- 

C=B642; port-s=7531 
Require: sec-agree 
Proxy-Require: sec-agree 
CSeq: 2 REGISTER 
Supported: path, outbound, gruu 
Content-Length: 



2. SIP REGISTER request (P-CSCF#1 to I-CSCF)-See example in table A.3.2-2 

After performing the DNS query, the P-CSCF#1 forwards the REGISTER request towards I-CSCF. The P-CSCF 
adds a Path header with a flow token and includes the 'ob' parameter 



Table A.3.2-2 SIP REGISTER request (P-CSCF#1 to I-CSCF) 



REGISTER sip : registrar . homel . net SIP/2.0 




Via: SIP/2. 0/UDP pcscf 1 .visitedl .net;branch=z9hG4bK240f34 . 1, SIP/2. 0/UDP 




[5555 : : aaa : bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 




Max-Forwards: 69 




P-Access-Network-Inf o : 




Path : <sip : VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@pcscf 1 .visitedl . net ; Ir ;ob> 




Require: path 




P-Visited-Network- ID : "Visited Network Number 1" 




P- Charging- Vector : icid-value= "AyretyU0dm+602IrT5tAFrbHLso=023551024 " 




From : 




To : 




Contact : 




Call-ID: 




Authorization: Digest username= "userl private@homel.net", realm= "registrar . homel . net " , 


nonce=base64 (RAND + AUTN + server specific data), algorithm=AKAvl -MD5 , 




uri=" sip: registrar .homel .net" , response= " 662 9f ae493 93a053 97450978507c4ef 1 " 


integrity- 


protected="yes " 




CSeq: 




Supported : 




Content-Length : 





3. SIP REGISTER request (I-CSCF to S-CSCF) 

The I-CSCF forwards the SIP REGISTER request to the S-CSCF. 

4. SIP 200 (OK) response (S-CSCF to I-CSCF)-See example in table A.3.2-4 

The S-CSCF sends a SIP 200 (OK) response to the I-CSCF indicating that Registration was successful. AS the 
URJ in the first path header field has an "ob" URI parameter, it include a Require header with the option-tag 
"outbound". 
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Table A.3.2-4: SIP 200 (OK) response (S-CSCF to l-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf l_p .homel .net ;branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1 . visitedl -net ;branch=z9hG4bK24 0f 34 . 1 , SIP/2 . 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp ; branch=z9hG4bKnashds7 
Path : <sip : termopcscf 1 .visitedl . net ; Ir ;ob> 
Service-Route : <sip : origOscscf 1 . homel . net ; lr> 
From : 
To : 

Call-ID: 

Contact: <sip: [5555 :: aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp> ; 

pub-gruu= " sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 0a0c91e6bf 6 " 
; temp-gruu= " sip : tgruu . 7hs== j d7vnzga5w7f aj sc7 -aj d6f abzOf 8g5@example . com; gr " 
; +sip . instance= " < urn : gsma : imei :90420156-025763-0 >"+g. 3gpp .icsi-ref = "urn%3Aurn- 7%3gpp- 
service . ims . icsi . mmtel " ; +g . 3gpp . ics = "principal " ; +g . 3gpp . access type="cellularl " 
;expires=600000 

CSeq: 

Supported: path, outbound 
Require : outbound 

Date: Wed, 11 July 2001 08:49:37 GMT 

P-Associated-URI : <sip : userl_public2@homel . net> , <sip : userl_public3@homel . net > , <sip:+l-212- 

555 -llllOhomel . net ; user=phone> 
Content-Length : 



5-6. SIP 200 (OK) response (I-CSCF to UE) 

The I-CSCF forwards the SIP 200 (OK) response to the UE via P-CSCF#1. 

7. SIP REGISTER request (S-CSCF to SCC AS)-See example in table A.3.2-7 

After UE successfully registered in the IM CN subsystem, the S-CSCF sends a third party REGISTER request to 
the SCC AS based on the initial filter criteria it received. 

Table A.3.2-7: SIP REGISTER request (S-CSCF to SCC AS) 



REGISTER sip: sccas.homel.net /2.0 

Via: SIP/2. 0/UDP scscfl .homel .net;branch=z9hG499ffhy 
Max- Forwards : 70 

From: <sip : scscfl . homel . net> ; tag=538ya 
To : <sip : userl_publicl@homel . net > 
Call-ID: lasdaddlrf jflslj40a222 

P-Access-Network-Info : 3GPP-UTRAN-TDD ; utran-cell-id-3gpp=234151D0FCEll 
Contact: <sip : scscfl . homel . net> ; expires=6 
CSeq: 87 REGISTER 

Content - Type : mult ipart /mixed ; boundary= " boundaryl " 
Content-Length: (...) 

- -boundaryl 

Content-Type: message/sip 

REGISTER sip : registrar . homel . net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK24 Of 34 . 1 , SIP/2 . 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

P-Access-Networ]<-Info : 3GPP-UTRAN-TDD ; utran-cell-id-3gpp = 234151D0FCEll 
Path: <sip : Vs]<.ztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@pcscf 1 .visitedl . net ; Ir ,-ob> 
Require: path 

P-Visited-Networ]<- ID : "Visited Networ]< Number 1" 

P- Charging- Vector : icid-value= "AyretyU0dm+6O2IrT5tAFrbHLso=02 3 551024 " 
From : <sip : userl_publicl®homel . net > ; tag=4f a3 
To: <sip : userl_publicl®homel . net > 

Contact: <sip: [5555 :: aaa :bbb : ccc : ddd] : 1357 ; comp=sigcomp> ; reg-id=l,- +sip . instance= " < 
urn : gsma : imei :90420156-025763-0>";+g. 3gpp .icsi-ref= "urn%3Aurn- 7%3gpp- 

service . ims . icsi . mmtel " ; +g . 3gpp . ics= "principal " j+g . 3gpp . access type="cellularl ";expires = 6 0000 
Call -ID: apb0 3a0s0 9d]<jdfgl]<j4 9111 

Authorization: Digest username= "userl_private@homel . net " , realm= " registrar . homel . net " , 

nonce=base64 {RAND + AUTN + server specific data), algorithm=AKAvl-MD5 , 

uri="sip : registrar .homel .net" , response= " 662 9f ae4 9393a053974 50978507c4ef 1 " 

CSeq: 2 REGISTER 

Supported: path, outbound, gruu 

Content-Length: 

- -boundaryl 
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Content-Type: message/sip 
SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf l_p . homel . net ;branch=z9hG4bK351g45 . 1 , SIP/2. 0/UDP 
pcscf 1 .visitedl .net ;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 : :aaa:bbb: ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Path: <sip: term@pcscf 1 .visitedl .net ; Ir ;ob> 
Service -Route : <sip : orig®scscf 1 . homel .net ; lr> 
From: <sip :userl_publicl@homel .net > ; tag=4f a3 
To: <sip:userl_publicl@homel .net>; tag=3ecl 
Call -ID: apb0 3aOs09dkjdfglkj4 9111 

Contact: <sip: [5555 :: aaa :bbb : ccc : ddd] : 1357 ; comp=sigcomp> ; 

pub-gruu= " sip : userlpubliclohomel . net ; gr=urn : uuid: f 81d4f ae- 7dec- lldO -a765-00a0c91e6bf 6 " 

; temp-gruu= " sip : tgruu . 7hs== j d7vnzga5w7f aj sc7-aj d6f abzOf 8g5@example . com; gr " 

; +sip . instance= " < urn : gsma : imei :90420156-025763-0>";+g. 3gpp . icsi-ref = "urn%3Aurn-7%3gpp- 

service . ims . icsi .mmtel" ; +g. 3gpp . ics= "principal "+g . 3gpp . accesstype="cellularl " 

;expires=600000 
Supported: path, outbound 
Require : outbound 

Date: Wed, 11 July 2001 08:49:37 GMT 

P-Associated-URI : <sip : userl_public2@homel .net> , <sip:userl_public3@homel .net>, <sip : +1-212 -555- 

llliohomel . net ; user=phone> 
CSeq: 2 REGISTER 
Content-Length: 

- -boundaryl- - 



8. SIP 200 OK response (SCC AS to S-CSCF) 

The SCC AS generates the SIP 200 (OK) response to the third party SIP REGISTER request. 

9. UE connects to a new IP-CAN 

The UE connects to a new IP-CAN and will perform the registration via the new IP-CAN. 

10. SIP REGISTER request (UE to P-CSCF#2)- See example in table A.3.2-10 

UE sends the unprotected SIP REGISTER request via the new IP-CAN to P-CSCF+2 which in this example is a 
different one with previous registration. 

Table A.3.2-10: SIP REGISTER request (UE to P-CSCF#2) 



REGISTER sip: registrar. homel. net SIP/2.0 

Via: SIP/2. 0/UDP [5555: : aaa : bbb : ccc : eee] ; comp=sigcomp;branch=z9hG4bKnasiuen8 
Max-Forwards: 70 

P-Access-Network-Info : IEEE-802 . lib 

From: <sip :userl_publicl®homel . net> ; tag=2hiue 

To : <sip :userl_publicl@homel . net > 

Contact: <sip : [5555 :: aaa : bbb : ccc : eee] ; comp=sigcomp> ; reg-id=2; +sip . instance= "< 
urn: gsma : imei : 90420156- 025763 -0>;+g. 3gpp . icsi-ref ="urn%3Aurn- 7 %3gpp- 

service . ims .icsi .mmtel" ; +g. 3gpp. ics= "principal" ; +g. 3gpp. accesstype="wlan2";expires=600000 
Call-ID: E05133BD26DD 

Authorization: Digest username="userl_private@homel .net" , realm="registrar .homel .net" , 

nonce="", uri= " sip : registrar . homel . net " , response^"" 
Security-Client: ipsec-3gpp; alg=hmac-sha-l-96 ; spi-c=23456789 ; spi-s=12345678 ; port-c=1234 ; 

port-s=5678 
Require: sec-agree 
Proxy-Require: sec-agree 
CSeq: 1 REGISTER 
Supported: path, outbound, gruu 
Content -Length: 



11-12. SIP REGISTER request (P-CSCF#2 to S-CSCF) 

The P-CSCF forwards the SIP REGISTER request towards S-CSCF via I-CSCF. Likewise in message #2, P- 
CSCF#2 adds a Path header with flow token and 'ob' parameter. 

13-15. SIP 401 (Unauthorized) response (S-CSCF to UE) 

The authentication challenge is sent in the SIP 401 (Unauthorized) response towards the UE. 
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16-18. SIP REGISTER request (UE to S-CSCF) 

The UE sends the protected SIP REGISTER request towards S-CSCF using contact#2. 
19-21. SIP 200 (OK) response (S-CSCF to UE) 

The S-CSCF sends a SIP 200 (OK) response towards the UE indicating that registration was successful. 
22. SIP REGISTER request (S-CSCF to SCC AS) 

The S-CSCF sends a third party REGISTER request to the SCC AS based on the initial filter criteria it received. 



Table A.3.2-22: SIP REGISTER request (S-CSCF to SCC AS) 



REGISTER sip: sccas.homel.net /2.0 




Via: SIP/2. 0/UDP scscf 1 . homel . net ; branoh=z9hG4 99f f hy 




Max-Forwards: 70 




From: <sip : scscf 1 . homel . net> ; tag=538ya 




To: <sip:userl put)licl@homel . net> 




P -Access -Network- Inf o : IEEE- 8 02. lib 




Call-ID: lasdaddlrf j f Islj 40a222 




Contact: < s ip : sc sc f 1 . homel . net > ; expires=6 




CSeq: 87 REGISTER 




Content — Type ■ mul t ipart /mixed; boundary = " boundary 1 " 




Content-Length: (...) 




- -boundaryl 




Content-Type: message/sip 




REGISTER sip : registrar . homel . net SIP/2.0 




Via: SIP/2. 0/UDP pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 . 1, SIP/2 . 0/UDP 




[5555 : : aaa : bbb : ccc : eee] : 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 




Max-Forwards: 69 




P-Access-Network-Info : IEEE-802 . lib 




Path: <sip : VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@pcscf 1 .visitedl . net ; Ir ;ob> 




Require: path 




P-Visited-Network- ID : "Visited Network Number 1" 




P- Charging- Vector : icid-value= "AyretyU0dm+6O2IrT5tAFrbHLso=02 3 551024 " 




From : <sip : userl_publicl®homel . net > ; tag=2hiue 




To: <sip : userl_publicl@homel . net > 




Contact: <sip: [5555: : aaa : bbb : ccc : eee] ; comp=sigcomp> ; reg- id=2 ; +sip . instance 


= " < 


urn : gsma : imei :90420156-025763-0>;+g. 3gpp .icsi-ref= "urn%3Aurn- 7%3gpp- 




service . ims . icsi . mmtel " ; +g . 3gpp . ics= "principal " ; +g . 3gpp . accesstype ="wlan2' 


;expires=600000 


Call -ID: apb0 3aOs0 9dkjdfglkj4 9111 




Authorization: Digest username="userl private@homel.net", realm= " registrar 


. homel . net " , 


nonce=base64 {RAND + AUTN + server specific data), algorithm=AKAvl-MD5 , 




uri="sip : registrar .homel .net" , response= " 662 9f ae4 9393a053974 50 97850 7c4ef 1 " 




CSeq: 3 REGISTER 




Supported: path, outbound, gruu 




Content-Length: 




- -boundaryl 




Content-Type: message/sip 




SIP/2.0 200 OK 




Via: SIP/2. 0/UDP icscfl p . homel . net ,-branch=z9hG4bK351g45 . 1 , SIP/2 . 0/UDP 




pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 




[5555 : : aaa : bbb : ccc : eee] : 1357 ; comp=sigcomp ;branch=z9hG4bKnashds7 




Path : <sip : termOpcscf 1 . visitedl . net ; Ir ; ob> 




Service-Route : <sip : origOscscf 1 . homel . net ; lr> 




From: <sip:userl publiclohomel . net> ; tag=2hiue 




To: <sip:userl publiclohomel . net> ; tag=2da87 




Call -ID: apb03a0s0 9dkjdfglkj4 9111 




Contact : <sip : [5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp> ; 




pub-gruu= " sip : userl publiclohomel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a76 5- 


00a0c91e6bf 6" 


; temp-gruu= " sip : tgruu . 7hs== j d7vnzga5w7f aj sc7-aj d6f abzOf 8g50example . com; gr " 




; +sip . instance= " <urn : gsma : imei :90420156-025763-0>";+g. 3gpp .icsi-ref= "urn%3Aurn- 7%3gpp- 


service . ims . icsi . mmtel " ; +g . 3gpp . ics= "principal " ; +g . 3gpp . accesstype="wlan2" 




;expires=600000 




Supported: path, outbound 




Require : outbound 




Date: Wed, 11 July 2001 08:49:37 GMT 




P-Associated-URI : <sip: userl public20homel . net> , <sip: userl public30homel . 


net>, <sip : +1-212-555- 


llllohomel . net ; user=phone> 




CSeq: 3 REGISTER 
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Content -Length; 
- -boundaryl - - 

23. SIP 200 (OK) response (SCC AS to S-CSCF) 

The SCC AS generates the SIP 200 response to the third party REGISTER request. 

A.4 Signalling flows for call origination for service 
continuity 

A.4.1 Session origination for CS calls 

An example flow for session origination for CS calls can be found in 3GPP TS 24.292 [4]. 

A.5 Signalling flows for call ternnination for service 
continuity 

A.5.1 Session ternnination using CS media 

An example flow for session termination using CS calls can be found in 3GPP TS 24.292 [4]. 

A.6 Signalling flows for PS-CS access transfer 
A.6.1 PS-CS access transfer: CS-PS 

In this example, SC UE A has an ongoing session with remote UE B over CS bearer before access transfer. When SC 
UE connects to an IP-CAN, it decides to transfer the session over the new IP-CAN. 
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SCUE A 
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1 . SC UE A is on an active session with UE B. Call is anchored at SCC AS. 



1 a.CS bearei* 



2. UE A connects to a new IP-CAN 
and decides to transfer the session 
over the new IP-CAN. It reserves 
resources in the new IP-CAN. 



■lb. IP bearer- 



-3. INVITE- 



4. iFC Evaluation 



—5. SIP INVITEH 



-14. SIP 200 (OK) iNviTir 
I 

15. SIP ACK 



I 20. DISCONNECT 

1-21. RELEASE 1 

122. RELEASE COMPLETE- 



I 



■17. IP bearer- 



-19. SIP BYE- 



-23. SIP 200 (OK)- 



6 Remote leg Update 



7. SIP 
■ relNVITE 



-8. SIP relNVITE- 



I 9. SIP 200 (OK),eiNviTir 

10. SIP 
200 (OK),.e,xviTE* 
1-11. SIP ACK — 
12. SIP ACK- 



13. SIP 

L2OO (OK) INVITE 



-16. SIP ACK- 



-18. SIPBYE- 



-24. SIP 200 (OK)» 



Figure A.6.1-1 : Signalling flow for PS-CS Access Transfer: CS to PS 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalhng flow. 

1. SC UE A has an ongoing session with remote UE B 

The call has been anchored at the SCC AS which is in the HPLMN of originating SC UE A. 

2. SC UE A connects to a new IP-CAN: 

The SC UE A decides to transfer the session over the new IP-CAN. The UE A obtains an IP address that it will 
use for the signalling and media. It registers with the S-CSCF over the new IP-CAN using standard registration 
procedure and reserves resources in the new IP-CAN. 

3. SIP INVITE request (SC UE A to intermediate IM CN subsystem entities) - see example in table A.6.1-3 

The SC UE A sends an initial INVITE request to request the new caU replaces the existing call. 
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Table A.6.1-3: SIP INVITE request (UE A to intermediate IM CN subsystem entities) 



INVITE sip : domain .xferOsccas . homel . net SIP/2.0 

Via: SIP/2. 0/UDP [5555: :aaa:bbb:ccc:ddd] : 1357 ; comp=sigcomp ; branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route: <sip : pcscfl . homel . net : 7531 ; Ir >, <sip : origOscscf 1 . homel . net ; lr> 
P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 
P-Access-Network-Info : IEEE-802 . lib 
Privacy: none 

From: <sip : userl_publicl@homel . net> ; tag=171828 

To: <tel : +l-237-555-2222> 

Call -ID: Cb0 3a0s09a2sdfglkj4 902 3 7 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 
Require: sec-agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; portl=7531 

Contact : <sip : userl_publicl@homel . net ; gr= urn : uuid: f 81d4f ae- 7dec- lld0-a765- 
00a0c91eGbfG>,•+g. 3gpp . icsi -ref = "urn%3Aurn- 7%3gpp- 
service . ims . icsi . mmtel " ; +g . 3gpp . ics= "principal " ; 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Accept: application/sdp ; application/3gpp- ims+xml 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s= 

c=IN IP6 5555: : aaa: bbb: ccc: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 
b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap : 97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxpt ime : 2 



4. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

5. SIP INVITE request (intermediate EM CN subsystem entities to SCC AS) 

The SIP INVITE request is forwarded to the SCC AS as the result of the evaluation of iPC. 

6. Remote Leg Update 

The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the Remote Leg. 

7. SIP re-EWITE request (SCC AS to intermediate IM CN subsystem entities)- See example in table A.6.1-7 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID headers from one side of the B2BUA to the other. In this example the SCC AS includes 
the contents of the Contact header from the received SIP INVITE request.The SIP re-INVITE request contains 
the SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP INVITE request from 
the UE A (Step 3). 
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Table A.6.1-7: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE < sip : userlpubliclohomel . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6> SIP/2.0 
Via: SIP/2. 0/UDP sccas.homel.net; branch=z9hG4bK332b33 . 3 ; 
Max-Forwards: 67 

Route: <scscf 1 . homel . net ; Ir > , <sip : scscf 2 . home2 . net ; lr> , <sip : pcscf 2 . visited2 . net ; lr> 
P-Asserted- Identity : "John Doe" <sip :userl_publicl@homel .net>, <tel : +l-237-555-llll> 
P-Access-Network-Info : IEEE-802 . lib 
Privacy: none 

P- Charging- Vector : icid-value= "AyretyU0dm+602IrT5tAFrbHLso=023 551024 " 
P-Charging-Function-Addresses : 

From: <sip : userl_publicl®homel . net> ; tag=1717777 

To: <tel : +l-237-555-2222>, tag=4321 

Call -ID: dcl4bltl0b3teghmlk50132 3 7 

Cseq: 111 INVITE 

Supported: precondition, lOOrel 

Contact : <sip : user2_publicl@home2 . net ;gr=urn : uuid : 2ad8 95 0e-4 8a5-4a74-8d99- 
adVSccVf c74 > ; +g . 3gpp . icsi -ref = "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s = 

c=IN IP6 5555: : aaa: bbb: ccc: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxpt ime : 2 



8. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B) 

The intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE B. 
9-10: SIP 200 (OK) response (UE B to SCC AS via Intermediate IM CN subsystem entities) 

The UE B generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the SCC AS. 
1 1-12: SIP ACK request (SCC AS to UE B via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the remote UE B. 
13-14: SIP 200 (OK) response (SCC AS to UE A via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request and forwards it to the SC UE A. 
15-16: SIP ACK request (SC UE A to SCC AS via Intermediate IM CN subsystem entities) 

The SC UE A generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the SCC AS 
17. Media paths between UE A and UE B 

The media path is using the new IP-CAN. 
18-19. SIP BYE request (SCC AS to interworldng entities via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the CS bearer, by sending a BYE request. 
20-22, ISUP Message 

Upon receiving the DISCONNECT request, the SC UE A relinquishes all resources pertaining to the CS bearer. 
23-24. SIP 200 (OK) response (Interworldng entities to SCC AS via intermediate IM CN subsystem entities) 
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A.6.2 PS-CS access transfer: PS-CS 

In this example, SC UE A has an ongoing session with remote UE B over PS bearer before access transfer which is 
anchored at SCC AS. When the SC UE attaches to the CS domain, it decides to transfer the session over the CS bearer 
without ICS capabiUty. 
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Figure A.6.2-1 Signalling flow for PS-CS access transfer: PS-CS 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. SC UE A is on an active session with UE B: 

There is an ongoing IP bearer between the SC UE and the remote end UE B. The call is achored at SCC AS. 

2. SC UE A attaches to the CS domain 

The SC UE attaches to the CS domain and decides to transfer the session over the CS bearer. 

3. CC SETUP messages 
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The SC UE sends the CS SETUP message with the static STN as the called party number. 

4. SIP INVITE request (InterworJdng entities to Intermediate EM CN subsystem entities) -see example in 
table A.6.2-4 

Table A.6.2-4: SIP INVITE request (interworking entities to intermediate IM CN subsystem entities) 



INVITE tel: +1-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mgcf 1 .homel .net;branch=z9hG4bk731b87 
Max- Forwards : 7 

Route : <sip : icscf 1 . homel . net ; lr> 
P-Asserted-Identity : <tel: +l-237-555-llll> 

P- Charging- Vector : icid-value= "AyretyU0dm+6O2IrT5tAFrbHLso=023 551024 " ; orig- ioi=homel . net 
Privacy: none 

From: <tel: +1-237- 555- 1111> ; tag=171828 
To: <tel: +l-237-555-3333> 
Call -ID: Cb03a0s09a2sdfglkj4 903 3 3 
Cseq: 127 INVITE 

Supported: lOOrel, precondition 

Accept -Contact : * ; +g . 3gpp . icsi-ref= "urn%3Aurn- 7%3gpp- service . ims . icsi .mmtel " 
P- Asserted- Service : urn : urn- 7 : 3gpp- service . ims . icsi . mmtel 

Contact : <sip : mgcf 1 . homel . net ; gr> ; +g . 3gpp . icsi-ref = "urn%3Aurn- 7%3gpp-service . ims .icsi .mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa: bbb: ccc : eee 

t = 

m=audio 3456 RTP/AVP 97 96 
a=tcap : 1 RTP/AVPF 
a=pcfg:l t=l 
b=AS : 2 5 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 20 



Request-URI: contains the IMRN, as obtained from CS networks signalling. 
SDP: The SDP contains preconfigured set of codecs supported by the MGW. 

5. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

6. SIP INVITE request (Intermediate IM CN subsystem entities to SCC AS) 

7. Remote Leg Update 

The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the Remote Leg. 

8. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) -see example in table A.6.2- 
8 

The SCC AS acting as a routing B2BUA generates a SIP INVITE request based upon the received SIP INVITE 
request and the information previously stored against this session and routes it towards UE B via the 
intermediate IM CN subsystem entities. 
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Table A.6.2-8: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE sip : user2publicl@home2 . net ;gr=urn : uuid : 2ad8 950e-4 8a5-4a74-8d99-ad76cc7f c74 SIP/2 . 
Via: SIP/2. 0/UDP sccasl .homel .net;branch=z9hG4bKjias34r5 
Max-Forwards: 67 

Route: <sip : scscfl . homel . net : lr> 
P-Asserted-Identity : <tel: +l-237-555-llll> 

P- Charging- Function- Addresses : ccf = [5555: :b9 9:c88:d7 7:eee] ; ccf = [5555: :a55 :b44 : c33 :d22] ; 

ecf= [5555: : If f : 2ee : 3dd : 4ee] ; ecf= [5555: : Saa : 7bb : 8cc : 9dd] 
P-Charging-Vector : icid-value= "BzyretyU0dm+6O2IrT5tAFrbHLso=023551034 " ; orig- 

ioi= " type3homel . net " 
Privacy: none 

From: <tel : +1-23 7 - 555 - 1111> ; tag=569812 
To: <tel :+l-237-555-2222>; tag=26545 
Call- ID: ddl3a0s09a2sdfglkj490378 
Cseq : 

Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a76 5 - 

0a0c91e6bf 6> ; +g . 3gpp . icsi -ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
Allow: 

Content-Type: Content-Length: 
v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa: bbb: ccc : eee 

t = 

m=audio 3456 RTP/AVPF 97 96 

b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxpt ime : 2 
m=message TCP/MSRP 98 
a=accept- types : text/plain 



9. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B) 

Intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE B. 

10. SIP 200 (OK) response (UE B to intermediate IM CN subsystem entities) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE B has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

11. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SIP re-INVITE request to 
the SCC AS in the originating network. 

12-13. SIP ACK request (SCC AS to UE B via IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request 
to the remote UE B. 

14-15. SIP 200 (OK) response (SCC AS to interworldng entities via IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request, and forwards the SIP 200 (OK) 
response to the interworking entities. 

16. ISUP CONNECT message (interworldng entities to SC UE A) 

17. ISUP CONNECT Response message (SC UE A to interworldng entities) 

18-19. SIP ACK request (interworldng entities to SCC AS via IM CN subsystem entities) 
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The interworking entities generate the SIP ACK request to the SIP 200 (OK) response, and forward it to the SCC 
AS. 

20. Media paths between SC UE A and UE B: 

The CS bearer is setup while the PS bearer is still existing. 

21-22: SIP BYE request (SCC AS to SC UE A via intermediate EM CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the old IP-CAN, by sending a BYE request to the 
UEA. 

23-24. SIP 200 (OK) response (SC UE A to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the BYE request over the old IP -CAN, the SC UE A sends a SIP 200 (OK) response over the old 
IP-CAN to the SCC AS. Subsequently, the SC UE A relinquishes all resources pertaining to the old IP-CAN. 

25. Media paths between SC UE A and UE B 

Finally, the session is transferred from PS bearer to CS bearer. 



A.7 Signalling flows for PS-PS access transfer 
A. 7.1 Introduction 

The signalhng flows for PS-PS access transfer demonstrate how a multimedia session is transferred from Source Access 
Leg to the Target Access Leg. The following signalling flows are included: 

- subclause A.7. 2 shows an example when all media of an ongoing communication session and the associated 
signalhng are transferred from Source Access Leg to the Target Access Leg; and 

- subclause A.7. 3 shows an example when not all media of an ongoing communication session are transferred 
from the Source Access Leg to the Target Access Leg. 

A.7.2 PS-PS access transfer with full media transfer 

The signalling flows shown in figure A. 7. 2-1 describes the PS-PS access transfer procedure when all media of an 
ongoing communication session and the associated signalling are transferred from one contact address of an UE to a 
different contact address of the same UE. No lower-level mechanism to support the access transfer is assumed or 
needed. 

In this example the UE-1 is on an active multimedia session with the UE-2 via one IP-CAN. After changing to a new 
IP-CAN, obtaining a new IP address, and discovering a P-CSCF, the UE-1 reserves resources in new IP-CAN prior to 
initiating the PS-PS access transfer procedure. When the PS-PS access transfer procedure is completed, the UE-1 
continues the multimedia session with the UE-2 on the new IP-CAN. In this example, when attaching to the new IP- 
CAN, it is irrelevant whether the UE-1 uses the same P-CSCF or a new P-CSCF. 

NOTE 1: This scenario requires that the UE-1 and the IMS network support simultaneous multiple registrations and 
requires that the UE-1 supports dual mode operation. 

NOTE 2: In this example flow, each call leg is uniquely identified with a respective dialog identifier consisting of 
the Call-ID, From tag, and To tag. 
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Figure A.7.2-1 : Signalling flow for session handover 

NOTE 3: For clarity, the SIP 100 (Trying) responses are not shown in the signalUng flow. 

1. UE-1 is on an active session with UE-2 

The UE-1 is in an active session with the UE-2. The call is anchored in the SCC AS. It is irrelevant which 
endpoint initiated the caU. Each caU leg is uniquely identified with a respective dialog identifier. The caU leg 
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over old IP-CAN is identified with "Call-ID= me03a0s09a2sdfgjkl491777", "From tag=64727891", and "To 
tag=77432r'. The UE-1 and UE-2 exchange media over the old IP-CAN, which is maintained while the UE-1 
initiates the handover procedure. 

2. UE-1 connects to new IP-CAN 

The UE-1 determines that a handover of the session is required. The UE-1 connects to the new IP-CAN. The 
UE-1 obtains an IP address that it will use for the signalling and media. 

3. UE-1 registers with intermediate EM CN subsystem entities over new IP-CAN 

The UE-1 registers with the S-CSCF over the new IP-CAN using the standard registration procedure. Depending 
on the UE-1 configuration, the discovery of the P-CSCF in the new IP-CAN may be needed. 

4. UE-1 acquires resources in new IP-CAN 

Based on the UE-1 and new IP-CAN capabilities, the UE-1 decides to use the same codec that was used over the 
old IP-CAN. The UE-1 reserves resources (e.g. QoS) in the new IP-CAN that will be needed for the signalling 
and transferred media, prior to sending the initial SIP INVITE request. 

5. SIP INVITE request (UE-1 to intermediate EM CN subsystem entities) - see example in table A.7.2-5 

The UE-1 sends initial SIP INVITE request with a new SDP offer to the UE-2 that indicates that the new call 
replaces the existing call. The initial SIP INVITE request establishes a dialog for signalling and specifies in the 
SDP the new contact address that will be used for media over the new IP-CAN. Upon sending the initial SIP 
INVITE request, the UE-1 is ready to receive the RTP packets either over the new IP-CAN or the old IP-CAN. 
The RTP packets may arrive over the new IP-CAN prior to the UE-1 receiving the SIP 200 (OK) response for 
the initial SIP INVITE request. 

Table A.7.2-5: SIP INVITE request (UE-1 to intermediate IM CN subsystem entities) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max - Forwards : 7 

Route : <sip :pcscf 1 . homel .net : 7531 ; Ir ; comp=sigcomp> , <sip : orig@scscf 1 .homel .net ; lr> 
P-Pref erred-Identity: "John Doe" <sip:userl_publicl@homel .net> 
P-Access-Network-Info: IEEE-802 . lib 

Privacy: none 

From: <sip : userl_publicl@homel .net> ; tag=171828 

To: <tel : +l-212-555-2222> 

Call -ID: Cb0 3a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 
Require: sec -agree; replaces 

Replaces: me03a0s0 9a2sdf gj kl491777 ; to-tag=774321 ; f rom-tag=64727891 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; portl=7531 

Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765- 
00a0c91e6bf 6> ; +g . 3gpp . icsi -ref = "urn%3Aurn-7%3gpp- 
service . ims . icsi . mmtel " ; +g . 3gpp . ics= "principal " 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Accept: application/sdp; application/3gpp- ims+xml 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s=- 

c=IN IP6 5555: : aaa: bbb: ccc: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 
b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxpt ime : 2 



ETSI 



3GPP TS 24.237 version 9.1.0 Release 9 



72 



ETSI TS 124 237 V9.1.0 (2010-01) 



Request-URI: the tel-URI of the destination, i.e. the UE-2. 

Require: the "replaces" option tag indicate that the support for Replace header is required. 
Replaces: specifies the existing call that will be replaced with the new call. 

SDP: specifies the new IP address that the UE-1 has acquired in the new IP-CAN, and indicates that the 
resources in the new IP-CAN have been acquired. 

6. Evaluation of initial filter criteria 

Upon the evaluation of the initial filter criteria, as this is an originating initial SIP INVITE request for a 
registered user, the S-CSCF routes the initial SIP INVITE request to the SCC AS. 

7. SIP EWITE request (intermediate EM CN subsystem entities to SCC AS) - see example in table A.7.2-7 

The initial INVITE request is forwarded from intermediate IM CN subsystem entities in the home network to the 
SCC AS. The SCC AS acts as a routeing B2BUA as specified in 3GPP TS 24.229 [2]. In this example the SCC 
AS includes the contents of the Contact header from the received SIP INVITE request. 

Table A.7.2-7: SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel .net ;branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 
pcscfl.homel.net;branch=z9hG4bK240f34 .1, SIP/2 . 0/UDP 
[5555 : : aaa :bbb : ccc : ddd] : 1357;comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 67 

Route: <sip : sccas . homel .net ; lr> 

Record-Route : <sip: scscf 1 .homel .net ; lr>, <sip:pcscf 1 .homel .net ; lr> 

P-Asserted-Identity : "John Doe" <sip:userl_publicl@homel .net>, <tel : +1-212 -555-llll> 
P-Access -Network- Info : Privacy : Require : replaces 

P- Charging- Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024 " ;orig- 
ioi=type3ashomel .net> 

P-Charging-Function-Addresses : ccf= [5555: :b99 : c88 : d77 : e66] ; ccf= [5555: : a55 :b44 : c33 : d22] ; 

ecf=[5555: : If f : 2ee : 3dd : 4ee] ; ecf=[5555: : 6aa : 7bb : 8cc : 9dd] 
From: <sip:userl_publicl@homel .net>; tag=171828 
To: <tel:+l-212-555-2222> 
Call-ID: 
Cseq : 

Supported : Replaces : Contact : 
Allow:Accept : Content-Type : 
Content -Length: (...) 

v= 
o= 
s= 
c= 

t=0 

m= 

b= 

a= 

a= 

a= 

a= 

a= 

a= 

a= 

a= 



8. Remote leg update 

The SCC AS based on the content of the Replaces header correlates the initial SIP INVITE request to the 
existing local and remote call legs of the existing concatenated end to end session between the UE-1 and UE-2. 
The SCC AS updates the remote call leg by sending a SIP re-INVITE request to the UE-2 containing the new 
SDP offer that it has received from the UE-1. 

9. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) - see example in table A.7.2-9 

The UE-2 is informed of the change in access leg by the SCC AS sending a SIP re-INVITE request to the S- 
CSCF. 
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The sec AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID headers from one side of the B2BUA to the other. In this example the SCC AS includes 
the contents of the Contact header from the received SIP INVITE request. The SIP re-INVITE request contains 
the SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP INVITE request from 
theUE-I (Step 5). 

Table A.7.2-9: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE < sip:user2 j)ublicl@home2 .net ; gr=urn :uuid: 2ad8950e-48a5-4a74 -8d99-ad76cc7f c74> SIP/2 . 
Via: SIP/2. 0/UDP sccas.homel.net; branch=z9hG4bK332b33 . 3 ; 
Max- Forwards : 67 

Route : <scscf 1 . homel .net ; lr> , <sip : scscf 2 . home2 .net ; lr> , <sip :pcscf 2 . visited2 .net ; lr> 
P-Asserted- Identity : P-Access -Network- Info : Privacy : P- Charging- Vector : icid- 

value="BzyretyU0dm+602IrT5tAFrbHLso=023 551034 " 
P-Charging-Function-Addresses : 

From: <sip :userl jiublicl@homel .net> ; tag=1717777 

To: <tel:+l-212-555-2222>, tag=4321 

Call- ID: dcl4bltl0b3teghmlk5013333 

Cseq: 111 INVITE 

Supported: 

Contact : < sip : user l_publicl@homel .net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a765- 
00a0c91e6bf 6>; +g. 3gpp . icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 
Allow: Accept: application/sdp 
Content -Type : 
Content -Length: (...) 

v=0 

0=2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 
s=- 

c= IN IP6 5555: : aaa: bbb: ccc: ddd 
t=0 

m=audio 3456 RTP/AVP 97 96 
b=AS:25.4 

a= curr:qos local sendrecv 

a= curr:qos remote none 

a= des:qos mandatory local sendrecv 

a= desiqos none remote sendrecv 

a= rtpmap:97 AMR 

a= fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a= rtpmap:96 telephone-event 
a= maxpt ime : 2 



Route: The SIP re-INVITE request contains the saved Ust of Route headers that the SCC AS has saved for the 
remote leg of the call. 

10. SIP re-INVITE request (intermediate IM CN subsystem entities to intermediate IM CN subsystem 
entities) - see example in table A.7.2-10 

In the originating network, the intermediate IM CN subsystem entities forward the SIP re-INVITE request to the 
intermediate IM CN subsystem entities in the terminating network. 
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Table A.7.2-10: SIP re-INVITE request (intermediate liVI CN subsystem entities to intermediate IM CN 

subsystem entities) 



INVITE < sip :user2_publicl®home2 . net ; gr=urn :uuid: 2ad8950e-4 8a5-4a74 - 8d99-ad76cc7f c74 > SIP/2.0 
Via: SIP/2. 0/UDP scscfl.homel. net ;branch=z9hG4bK240f 34.1, SIP/2. 0/UDP sccas.homel.net; 

branch= z 9hG4bK3 3 2b3 3 . 3 ; 
Max-Forwards: 66 

Route : <sip : scscf 2 .home2 .net ; lr>, <sip :pcscf 2 . visited2 .net ; lr> 

P-Asserted- Identity: 

Privacy: none 

From: 

To: 

Call-ID: 

Cseq : Supported: Contact : <sip :userl_publicl®homel . net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765- 
00a0c91e6bf 6> ; +g. 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 

Allow: 
Accept : 

Content - TypeCont ent - Length : 

v= 

o= 

s=- 

c= 

t= 

m= 

b= 

a= 

a= 

a= 

a= 

a= 

a= 

a= 



11. SIP re-INVITE request (intermediate EM CN subsystem entities to UE-2) 

In the terminating network, the SIP re-INVITE request is forwarded towards the UE-2 by the intermediate IM 
CN subsystem entities. 

12. Media paths between UE-1 and UE-2 

The UE-2 receives the SIP re-INVITE request containing the SDP offer that indicates that the UE-1 is ready to 
receive the same media on a different contact address. Since the UE-2 has resources already available, it starts to 
send the media to the UE-l's contact address specified in the SDP offer immediately. 

The UE-1 will be receiving the RTP packets over new IP-C/VN. However, the UE-1 can receive some out-of- 
sequence RTP packets over the old IP-CAN. The RTP packets are delivered to the codec in sequence. Once the 
UE-1 determine that no media will be received over the old IP-C/VN (e.g. by examining the sequence numbers in 
the RTP headers), it can relinquish the resources that it has been using for incoming media on the old IP-CAN. 

The UE-1 sends the media to the UE-2 over the old IP-CAN. 

Resources used for signalling on the old IP-CAN are not released. 

13. SIP 200 (OK) response (UE-2 to intermediate IM CN subsystem entities) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE-2 has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

14. SIP 200 (OK) response (intermediate IM CN subsystem entities to intermediate IM CN subsystem entities) 

In the terminating network, the intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the 
SIP re-INVITE request to the intermediate IM CN subsystem entities in the originating network. 

15. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities in the originating network forward SIP the 200 (OK) response to the 
SIP re-INVITE request to the SCC AS. 
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16. SIP ACK request (SCC AS to intermediate EM CN subsystem entities) 

The SCC AS acting as a B2BUA acknowledges the receipt of the SIP 200 (OK) response to the SIP re-INVITE 
request by forwards a SIP ACK request to the intermediate IM CN subsystem entities. 

17. SIP ACK request (intermediate IM CN subsystem entities to intermediate EM CN subsystem entities) 

In the originating network, the intermediate IM CN subsystem entities forward the SIP ACK request to the 
intermediate IM CN subsystem entities in the terminating network. 

18. SIP ACK request (intermediate EM CN subsystem entities to UE-2) 

In the terminating network, the intermediate IM CN subsystem entities forward the SIP ACK request to the UE- 
2. 

19. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS forwards the SIP 200 (OK) response to the initial SIP INVITE request to the intermediate IM CN 
subsystem entities, using the content of the Via header that was received in the initial INVITE request (step 5). 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID headers from one side of the B2BUA to the other. The SIP 200 (OK) response to the initial 
SIP INVITE request contains the SDP answer that is identical to the SDP answer that the SCC AS has received 
in the SIP 200 (OK) response to SIP re-INVITE request from the UE-2 (Step 13). 

20. SIP 200 (OK) response (intermediate IM CN subsystem entities to UE-1) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the UE-1. 

21. Media paths between UE-1 and UE-2 

The UE-1 receives the SIP 200 (OK) response containing the SDP answer that indicates that the UE-2 is ready to 
receive media. Since the UE-1 has already resources available, it starts to send media over new IP-CAN to the 
UE-2's contact address specified in the SDP answer immediately. 

The UE-1 may relinquish the resources that it has been using for outgoing media on the old IP-CAN. 
Resources used for signalling on the old IP -CAN are not released. 

22. SIP ACK request (UE-1 to intermediate EM CN subsystem entities) 

The UE-1 completes the new call leg creation with a SIP ACK request sent to the intermediate IM CN subsystem 
entities. 

23. SIP ACK request (-intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the SCC AS. 

24. SIP BYE request (SCC AS to intermediate EM CN subsystem entities) 

The SCC AS terminates the replaced call leg- that was using the old IP-CAN, by sending a SIP BYE request to 
the UE-1. 

25. SIP BYE request (intermediate EM CN subsystem entities to UE-1) 

The intermediate IM CN subsystem entities forward the BYE request to the UE-1. 

26. SIP 200 (OK) response (UE-1 to intermediate EM CN subsystem entities) 

Upon receiving the SIP BYE request over the old IP-CAN, the UE-1 sends a SIP 200 (OK) response over the old 
IP-CAN. Subsequently, the UE-1 relinquishes all resources pertaining to the old IP-CAN. 

27. SIP 200 (OK) response (intermediate EM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SCC AS. 
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A.7.3 PS-PS access transfer with partial media transfer 

The signalling flows shown in figure A.7.3-1 describes the PS-PS access transfer procedure when not all media of an 
ongoing communication session are transferred from the Source Access Leg to the Target Access Leg. No lower-level 
mechanism to support the access transfer is assumed or needed. 

In this example, UE-1 is on an active multimedia session with UE-2 via one IP-CAN. After connecting to an additional 
IP -CAN, obtaining an additional IP address, discovering a P-CSCF, and performing IMS registration, UE-1 reserves 
resources in the new IP-CAN prior to initiating the PS-PS access transfer procedure. When the PS-PS access transfer 
procedure is completed, UE-1 continues the multimedia session with UE-2 on both the old and the new IP-CANs. In 
this example, when attaching to the new IP-CAN, it is irrelevant whether the UE-1 uses the same P-CSCF or a new 
P-CSCF. 

NOTE 1: This scenario requires that UE-1 and the IMS network support simultaneous multiple registrations and 
requires that UE-1 supports dual mode operation. 
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Figure A.7.3-1 : Signalling flow for PS-PS session transfer with partial media transfer 

NOTE 2: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. UE-1 is on an active session with UE-2 

UE-1 is in an active session with UE-2. The call is anchored in the SCC AS. It is irrelevant which endpoint 
initiated the call. Each call leg is uniquely identified with a respective dialog identifier. The call leg over IP- 
CAN #1 is identified with "Call-ID= me03a0s09a2sdfgjkl491777", "From tag=64727891", and "To 
tag=77432r'. UE-1 and UE-2 exchange media over the IP-CAN #1, which is maintained while the UE-1 initiates 
the session transfer procedure. 



2. UE-1 connects to IP-CAN #2 
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UE-1 connects to the new IP-CAN and obtains an IP address that it will use for the signalling and media. 

3. UE-l registers with intermediate EM CN subsystem entities over IP-CAN #2 

UE-1 registers with the S-CSCF over the IP-CAN #2 using the standard registration procedure. The P-CSCF in 
the signalling path of this registration may be distinct from the one used in the signalling path over IP-CAN #1. 

4. UE-1 acquires resources in IP-CAN #2 

UE-1 decides to perform partial media transfer to the IP-CAN #2. Based on UE-1 and IP-CAN #2 capabilities, 
the UE-1 decides to use the same codec that was used over the IP-CAN #1 for the media components to be 
transferred. UE-1 ensures that the resources (e.g. QoS) in IP-CAN #2 that wiU be needed for the signalling and 
transferred media are available, prior to sending the initial SIP INVITE request. 

5. SIP INVITE request (UE-1 to intermediate EM CN subsystem entities) - see example in table A.7.3-5 

UE-1 sends initial SIP INVITE request with a new SDP offer to UE-2 and indicates that the video component is 
to be transferred to IP-CAN #2. The initial SIP INVITE request establishes a dialog for signalling and specifies 
in the SDP new contact address that will be used for media over IP-CAN #2. Upon sending the initial SIP 
INVITE request, UE-1 is ready to receive the RTP packets over both IP-CAN #1 and IP-CAN #2. 

Table A.7.3-5: SIP INVITE request (UE-1 to intermediate IIUI CN subsystem entities) 



INVITE tel : +1-212-555-2222 SIP/2 . 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 7 

Route : sip : pcscf 1 . homel . net : 75 3 1 ; Ir ; comp=sigcomp> , <sip : origOscscf 1 . homel .net ; lr> 
P-Pref erred-Identity: "John Doe" <sip :userl_publicl@homel . net> 
P-Access-Network-Info: IEEE-802 . lib 
Privacy: none 

From: <sip :userl_publicl®homel .net>; tag=171828 

To: <tel : +l-212-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj4 90333 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 
Require: sec-agree; tdialog 

Target -Dialog: me03a0s09a2sdf gjkl491777 ; remote- tag=77432 1 ; local-tag=64727891 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; portl=7531 

Contact : < sip: user l_publicl@homel . net ;gr=urn:uuid : f 81d4f ae-7dec-lld0-a765- 
00a0c91e6bf 6> ; +g. 3gpp . icsi-ref ="urn%3Aurn-7%3gpp- 
service . ims . icsi . mmtel " ; +g . 3gpp . ics= "principal " ; 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Accept: application/sdp; application/3gpp- ims+xml 

Content -Type : application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s=- 

c=IN IP6 5555: : aaa: bbb: ccc: ddd 
t=0 

m=audio RTP/AVP 97 96 
a= r tpmap : 9 7 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a= r tpmap : 9 6 tel ephone - event 
m=video 3400 RTP/AVP 98 99 
b=AS:75 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des : qos mandatory local sendrecv 

a=des : qos none remote sendrecv 

a=rtpmap:98 H2 63 

a=fmtp:98 prof ile - level - id=0 

a=rtpmap:99 MP4V-ES 



Request-URI: the tel-URI of the destination, i.e. the UE-2. 

Require: the "tdialog" option tag indicate that the support for Target-Dialog header is required. 
Target-Dialog: specifies the existing call that will be transferred. 
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SDP: specifies the new IP address that the UE-1 has acquired in the new IP-CAN, and indicates that only the 
video component will be transferred and the resources in the new IP-CAN have been reserved. 

6. Evaluation of initial filter criteria 

Upon the evaluation of the initial filter criteria, as this is an originating initial SIP INVITE request for a 
registered user, the S-CSCF routes the initial SIP INVITE request to the SCC AS. 

7. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 

The initial SIP INVITE request is forwarded from intermediate IM CN subsystem entities in the home network 
to the SCC AS. The SCC AS acts as a routeing B2BUA as specified in 3GPP TS 24.229 [2]. 

8. Remote leg update 

Based on the content of the Target-Dialog header, the SCC AS correlates the SIP INVITE request for session 
transfer to the existing local and remote call legs of the existing concatenated end to end session between UE-1 
and UE-2. The SCC AS updates the remote call leg by sending a SIP re-INVITE request to the UE-2 containing 
the new SDP offer based on the partial media transfer request received from UE-1 and the negotiated SDP for 
the original session. 

9. SEP re-INVITE request (SCC AS to intermediate EM CN subsystem entities) - see example in table A.7.3-9 

UE-2 is informed of the change in access leg by the SCC AS sending a re-lNVlTE request to the S-CSCF. 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID headers from one side of the B2BUA to the other. In this example the SCC AS includes 
the contents of the Contact header from the received SIP INVITE request. The SIP re-INVITE request contains 
the SDP offer that is based on original SDP offer and the SDP offer that the SCC AS received in the initial SIP 
INVITE request from the UE-1 (Step 7). 
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Table A.7.3-9: SIP re-INVITE request (SCC AS to intermediate IIUl CN subsystem entities) 



INVITE < sip : user2 publicl@home2 . net ;gr=urn : uuid : 2ad8 950e-4 8a5-4a74-8d99-ad76cc7f c74> SIP/2 . 0> 
Via: SIP/2. 0/UDP sccas.homel.net; branch=z9hG4bK332b33 . 3 ; 
Max-Forwards: 70 

Route: <scscf 1 . homel . net ; lr> , <sip : scscf 2 . home2 . net ; lr> , <sip : pcscf 2 . visited2 . net ; lr> 
P-Asserted-Identity: "John Doe" <sip:userl_publicl@homel .net>, <tel : +1-212 -555-llll> 

Privacy: none 

P- Charging- Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024 " 

P-Charging-Function-Addresses : 

From: <sip : userl_publicl@homel . net> ; tag=1717777 

To: <tel : +l-212-555-2222>, tag=4321 

Call-ID: dcl4bltl0b3teghmlk5013333 

Cseq: 111 INVITE 

Supported: precondition, lOOrel 

Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lld0-a765- 
00a0c91e6bf 6> ; +g . 3gpp . icsi -ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

0=2987933100 2987933101 IN IP6 5555 : : aaa :bbb : ccc : eee 

s = - 
t = 

m=audio 3456 RTP/AVP 97 96 
c=IN IP6 5555 :: aaa :bbb : ccc : eee 
b=AS : 25 . 4 

a= curr:qos local sendrecv 

a= curr:qos remote none 

a= des:qos mandatory local sendrecv 

a= des:qos none remote sendrecv 

a= rtpmap:97 AMR 

a= fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 

a= rtpmap:96 telephone-event 

a= maxptime:20 

m=video 3400 RTP/AVP 98 99 

c=IN IP6 5555: :aaa:bbb:ccc:ddd 

b=AS : 75 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



Route: The SIP re-INVITE request contains the saved list of Route headers that the SCC AS has saved for the 
remote leg of the call. 

SDP: specifies the new IP address and ports used for the media components. In this case, the audio component is 
still using the original address and port while the video component is using the new IP address and new port 
allocated. 

10. SIP re-INVITE request (intermediate EM CN subsystem entities to intermediate EM CN subsystem 
entities) 

In the originating network, the intermediate IM CN subsystem entities forward the SIP re-INVITE request to the 
intermediate IM CN subsystem entities in the terminating network. 

11. SIP re-INVITE request (intermediate EM CN subsystem entities to UE-2) 

In the terminating network, the SIP re-INVITE request is forwarded towards UE-2 by the intermediate IM CN 

subsystem entities. 

UE-2 receives the SIP re-INVITE request containing the SDP offer that indicates that UE-1 is ready to receive 
video media on a different contact address. Since UE-2 has resources already available, it starts to send the 
media to UE-l's contact address specified in the SDP offer inamediately. 

UE-1 starts receiving the video RTP packets over IP-CAN #2. However, UE-1 may receive some out-of- 
sequence video RTP packets over IP-CAN #1. The video RTP packets are delivered to the codec in sequence. 
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Once UE-1 determine that no video will be received over IP-CAN #1 (e.g. by examining the sequence numbers 
in the RTP headers), it may rehnquish the resources that it has been using for incoming video media on IP-CAN 
#1. 

At the same time, UE-1 still sends both the audio and video media to UE-2 over IP-CAN #1. 

Resources used for signalling on IP-CAN #1 are not released. 

12. SIP 200 (OK) response (UE-2 to intermediate IM CN subsystem entities) - see example in table A.7.3-12 

Upon receiving the SIP re-INVITE request containing the SDP offer, since UE-2 has all resources available, it 
sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

Table A.7.3-12: SIP 200 (OK) response (UE-2 to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2 . 0/UDP pcscf 2 . visited2 .net : 5088 ; comp=sigcomp;branch=z9hG4bK361k21 . 1 , 

SIP/2 . 0/UDP scscf2 .home2 .net;branch=z9hG4bK764z87 .1, 

SIP/2 . 0/UDP scscfl. homel.net ;branch=z9hG4bK332b23 .1, 

SIP/2 . 0/UDP sccas.homel.net;branch=z9hG4bK332b33 .3 
Record-Route : <sip:pcscf 2 . visited2 .net : 5088 ; Ir ; comp=sigcomp> , <sip: scscf 2 .home2 .net ; lr>, 

<sip : scscfl .homel .net; lr> 
P-Access -Network- Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
Privacy: none 

From: <sip :userl_publicl@homel . net> ; tag=1717777 

To: <tel:+l-212-555-2222>;tag=4321 

Call- ID: dcl4bltl0b3teghmlk5013333 

CSeq: 111 INVITE 

Supported: precondition, lOOrel 

Contact : <sip : user2_publicl®home2 . net ;gr=urn : uuid : 2ad8 95 0e-4 8a5-4a74-8d99- 

ad76cc7f c74 > ; +g . 3gpp . icsi -ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel " > 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933623 2987933624 IN IP6 5555 : : eee : f f f : aaa :bbb 
s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

t=0 

m=audio 6544 RTP/AVP 97 96 
b=AS : 2 5 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote sendrecv 
a=des:qos mandatory local sendrecv 
a=des:qos mandatory remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxpt ime : 2 

m=video 10001 RTP/AVP 98 99 
b=AS : 75 

a=curr:qos local sendrecv 
a=curr:qos remote sendrecv 
a=des:qos mandatory local sendrecv 
a=des:qos mandatory remote sendrecv 
a=rtpmap:98 H263 
a=fmtp:98 prof ile-level-id=0 
a=rtpmap:99 MP4V-ES 



13. SIP 200 (OK) response (intermediate IM CN subsystem entities to intermediate IM CN subsystem 
entities) 

In the terminating network, the intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the 
SIP re-INVITE request to the intermediate IM CN subsystem entities in the originating network. 

14. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities in the originating network forward the SIP 200 (OK) response to the 
SIP re-EWITE request to the SCC AS. 
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15. SIP ACK request (SCC AS to intermediate EM CN subsystem entities) 

The SCC AS acting as a B2BUA acknowledges the receipt of the SIP 200 (OK) response to the SIP re-INVITE 
request by forwards a SIP ACK request to the intermediate IM CN subsystem entities. 

16. SIP ACK request (intermediate IM CN subsystem entities to intermediate EM CN subsystem entities) 

In the originating network, the intermediate IM CN subsystem entities forward the SIP ACK request to the 
intermediate IM CN subsystem entities in the terminating network. 

17. SIP ACK request (intermediate IM CN subsystem entities to UE-2) 

In the terminating network, the intermediate IM CN subsystem entities forward the SIP ACK request to UE-2. 

18. SIP 200 (OK) response (SCC AS to intermediate EM CN subsystem entities) - see example in table A.7.3- 
18 

The SCC AS forwards the SIP 200 (OK) response to the initial SIP INVITE request to the intermediate IM CN 
subsystem entities, using the content of the Via header that was received in the initial SIP INVITE request (step 
5). 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID headers from one side of the B2BUA to the other. In this example the SCC AS includes 
the contents of the Contact header from the received SIP 200 (OK) response. The SIP 200 (OK) response to the 
initial SIP INVITE request contains the SDP answer derived from the SDP answer that the SCC AS has received 
in the SIP 200 (OK) response to SIP re-INVITE request from UE-2 (Step 14). 

Table A.7.3-18: SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 .homel .net;branch=z9hG4bK332b23 . 1, 
SIP/2 . 0/UDP pcscf 1 .homel .net ;branch=z9hG4bK24 0f 34 .1, 

SIP/2. 0/tJDP [5555: : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Record-Route : <sip: sccas . homel .net ; lr> , <sip : scscf 1 .homel .net ; lr>, <s ip: pcscf 1 .homel .net ; lr> 
Privacy: none 

From: <sip : userl_publicl@homel . net> ; tag=171828 
To: <tel : +l-212-555-2222>; tag=8009 
Call- ID: Cb03a0s09a2sdfglkj490333 
Cseq: 127 INVITE 

Supported: lOOrel; precondition 

Contact : < sip : user2_publicl®home2 . net ; gr=urn : uuid: 2ad8950e-4 8a5-4a74 - 8d99- 
ad76cc7f c74> ; +g . 3gpp . icsi -ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp; 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IP6 5555 :: eee : fff : aaa :bbb 
s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 
t=0 

m=audio RTP/AVP 97 96 
a= r tpmap : 9 7 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone -event 
m=video 10001 RTP/AVP 98 99 
b=AS:75 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des : qos mandatory local sendrecv 

a=des : qos mandatory remote sendrecv 

a=rtpmap:98 H2 63 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



19. SIP 200 (OK) response (intermediate IM CN subsystem entities to UE-1) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to UE-1. 
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UE-1 receives the SIP 200 (OK) response containing the SDP answer indicating that UE-2 is ready to receive 
media. Since UE-1 has already resources available, it starts to send video media over IP-CAN #2 to UE-2's 
contact address specified in the SDP answer immediately. 

The UE-1 may relinquish the resources that it has been using for outgoing video media on IP-CAN #1. 
Resources used for signalling and audio media on IP-CAN #1 are not released. 

20. SIP ACK request (UE-1 to intermediate IM CN subsystem entities) 

UE-1 completes the new call leg creation with a SIP ACK request sent to the intermediate IM CN subsystem 
entities. 

21. SIP ACK request ( intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the SCC AS. 

22. SIP re-INVITE request (UE-1 to intermediate EM CN subsystem entities) - see example in table A.7.3-22 

UE-1 updates the old call leg on IP-CAN #1 by sending a SIP re-INVITE request to the intermediate IM CN 
subsystem entities. 

Table A.7.3-22: SIP re-INVITE request (UE-1 to intermediate IM CN subsystem entities) 



INVITE <sip :user2_publicl@home2 . net ; gr=urn : uuid : 2ad8950e-4 8a5-4a74 - 8d99-ad76cc7f c74> SIP/2 . 
Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : eee] : 2468 ; comp=sigcomp ;branch=z9hG4bKashdnsl 
Max-Forwards: 70 

Route : sip : pcscf 1 . homel . net : 8 76 5 ; Ir ; comp=sigcomp> , <sip : origOscscf 1 . homel . net ; lr> 
P- Access -Network- Info: 3GPP-UTRAN-FDD; utran-cell-id-3gpp=123456ABCDE22 

Privacy: none 

From: <sip : userl_publicl@homel . net> ; tag=64727891 
To: <tel : +l-212-555-2222>; tag=774321 
Call -ID: me0 3a0s09a2sdfgjkl4 91777 
Cseq: 101 INVITE 

Supported: lOOrel; precondition; tdialog 
Require: sec -agree ; 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=12345678 ; portl=2468 

Contact : <sip : userl_publicl®homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a765- 
00a0c91eSbfS>,•+g. 3gpp . icsi -ref = "urn%3Aurn- 7%3gpp- 
service . ims . icsi . mmtel " ; +g . 3gpp . ics= "principal " ; 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Accept: application/sdp; application/3gpp-ims+xml 

Content-Type: application/sdp 

Content -Length: (...) 

v=0 

o=- 2987933000 2987933001 IN IP6 5555 :: aaa :bbb : ccc : eee 
s=- 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 
t=0 

m=audio 3456 RTP/AVP 97 96 
b=AS : 2 5 . 4 
a=rtpmap : 97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone-event 

m=video RTP/AVP 98 99 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



23. SIP re-INVITE request (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP re-lNVlTE request to the SCC AS. 

24. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) - see example in table A.7.3- 
24 

The SCC AS updates the old call leg based on the SIP re-lNVlTE request and sends the SIP 200 (OK) response 
to the SIP re-INVITE request to the intermediate IM CN subsystem entities, using the content of the Via header 
that was received in the SIP re-INVITE request (step 23). In this example the SCC AS includes the contents of 
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the Contact header from the received SIP 200 (OK) response. The SIP 200 (OK) response to the SIP re-INVITE 
request contains the SDP answer derived from the SDP answer that the SCC AS previously received from UE-2 
(Step 14). 

Table A.7.3-24: SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 .homel .net ;branch=z9hG4bK345b32 . 2 , 
SIP/2 . 0/UDP pcscfl .homel .net ;branch=z9hG4bK56 8f 3 5 . 1 , 

SIP/2 . 0/UDP [5555 : : aaa : bbb : ccc : eee] : 2468 ; comp=sigcomp;branch=z9hG4bKashdnsl 
Record-Route : <sccas . homel . net ; lr> , <sip : scscf 1 . homel . net ; lr> , <sip :pcscf 1 . homel . net ; lr> 
Privacy: none 

From: <sip : userl_publicl®homel . net > ; tag=64727891 
To: <tel : +1-212 -555 -2222 >;tag=774321 
Call -ID : me 3aOs0 9a2sdfgjkl4 91777 
Cseq: 101 INVITE 

Supported: lOOrel; precondition 

Contact : < sip : user2_publicl@home2 . net ;gr=urn : uuid : 2ad8 95 Oe-4 8a5 -4a74 - Sdgg- 
adVSccVf c74 > ; +g . 3gpp . icsi -ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp; 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933800 2987933801 IN IP6 5555 :: eee : fff : aaa :bbb 

s = - 

c=IN IP6 5555: :eee:fff :aaa:bbb 

t = 

m=audio 6544 RTP/AVP 97 96 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 

a = r tpmap : 9 6 t e 1 ephone - event 

m=video RTP/AVP 98 99 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 iyiP4V-ES 



25. SIP 200 (OK) response (intermediate IM CN subsystem entities to UE-1) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to UE-1. 

26. SIP ACK request (UE-1 to intermediate IM CN subsystem entities) 

UE-1 completes the old call leg update with a SIP ACK request sent to the intermediate IM CN subsystem 

entities. 

27. SIP ACK request ( intermediate EM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the SCC AS. 



A.8 Signalling flows for PS-PS access transfer in 
conjunction with PS-CS access transfer 

A.8.1 Introduction 

The signalling flows for PS-PS access transfer conjunction with PS-CS access transfer demonstrate how a multimedia 
session is tranferred from Source Access Leg to the Target Access Leg. The following signalling flows are included: 

subclause A. 8. 2 shows an example when a multimedia session is transferred from one IP-C/VN to a new IP-CAN 
and the CS bearer respectively ; and 

- subclause A.8. 3 shows an example when a multimedia session is transferred from one IP-CAN and CS bearer to 
a new IP-CAN. 
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A.8.2 PS - PS in conjunction with PS - CS Access Transfer: PS to 
CS 

In this example, SC UE A has an ongoing multimedia session with remote UE B over IP-CAN#1 before access transfer. 
When SC UE connects to a new IP-CAN#2, it decides to transfer the multimedia session over the new IP-CAN#2 and 
the CS bearer respectively. 
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Figure A.8.2-1 : Signalling flow for PS - PS in conjunction with PS - CS Access Transfer: PS to CS 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalUng flow. 

1. SC UE A has an ongoing multimedia session with remote UE B 

The call has been anchored at the SCC AS which is in the HPLMN of originating SC UE A. The call leg over 
old IP-CAN is identified with "Call-ID= me03a0s09a2sdfgjkl491777", "From tag=64727891", and "To 
tag=774321". The UE A and UE B exchange media over the old IP-CAN, which is maintained while the SC UE 
A initiates the handover procedure. 

Table A.8.2-1 shows an example of the SDP offer from SC UE A to remote UE B. 

NOTE 2: To later show how the media is transferred to the new IP-CAN and CS bearer, only the SDP offer is 
shown in table A.8.2-1. 

Table A.8.2-1 : SIP INVITE request (SC UE A to intermediate IM CN subsystem entities) 



INVITE tel:+l-237-555-2222 SIP/2.0 
Via: 

Max- Forwards : 
Route : 

P-Asserted- Identity: 

P-Charging-Vector : 

P-Access -Network- Info: 

Privacy: 

From: 

To: 

Call-ID: 
Cseq: 

Supported: 
Require : 
Proxy-Require : 
Security-Verify: 
Contact : 
Allow: 
Accept : 
Content -Type : 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 
s= 

c=IN IP6 5555: : aaa: bbb: ccc: ddd 
t=0 

m=audio 3456 RTP/AVP 97 96 
b=AS:25.4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des : qos mandatory local sendrecv 
a=des : qos none remote sendrecv 
a= r tpmap : 9 7 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxpt ime : 2 

m=message 7654 TCP/MSRP 98 
a=accept- types : text/plain 



2. SC UE A connects to a new IP-CAN#2: 

The SC UE A decides to transfer the multimedia session over the new IP-CAN and CS bearer respectively. The 
UE A obtains an IP address that it will use for the signalling and media. It registers with the S-CSCF over the 
new IP -CAN using multiple registrations procedure. Depending on the UE A configuration, the discovery of the 
P-CSCF in the new IP-CAN may be needed. Based on the UE A and new IP-CAN capabilities, the UE A decides 
to use the same codec that was used over the old IP-CAN. The UE A reserves resources (e.g. QoS) in the new 
IP-CAN that will be needed for the signalling and transferred media, prior to sending the initial SIP INVITE 
request. 

3. SIP INVITE request (SC UE A to intermediate EM CN subsystem entities)- see example in table A.8.2-3 
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The SC UE A sends an initial SIP INVITE request with a STI and a new SDP offer to the UE B that indicates 
that the new call replaces the existing call. The initial SIP INVITE request establishes a dialog for signalling and 
specifies in the SDP a new contact address that will be used for non-realtime media over the new IP-CAN. Upon 
sending the initial SIP INVITE request, the UE A is ready to receive the RTP packets either over the new IP- 
CAN or the old IP-CAN. The RTP packets may arrive over the new IP-CAN prior to the SC UE are receiving 
the SIP 200 (OK) response for the initial SIP INVITE request. 

Table A.8.2-3: SIP INVITE request (UE A to intermediate IM CN subsystem entities) 



INVITE tel : +1-237-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb: ccc : f f f ] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : sip : pcscf 1 . homel . net : 75 31 ; Ir ; comp=sigcomp> , <sip : origOscscf 1 . homel .net ; lr> 
P-Pref erred-Identity: "John Doe" <sip :userl_publicl@homel . net> 
P-Access-Network-Info: IEEE-802 . lib 
Privacy: none 

From: <sip : userl_publicl@homel .net> ; tag=171828 

To: <tel : +l-237-555-2222> 

Call -ID: Cb0 3a0s09a2sdfglkj4 90237 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 
Require: sec-agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; portl=7531 
Contact : <sip : userl_publicl®homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a765- 

0a0c91eGbfG>;+g. 3gpp . icsi -ref = "urn%3Aurn- 7%3gpp- 

service . ims . icsi . mmtel " ; +g . 3gpp . ics= "principal " ; 
Target -Dialog: me 3aOs0 9a2sdfgjkl4 91777; to-tag=774321 ; f rom-tag=64 72 7891 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp ; application/3gpp- ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : fff 

s= 

t = 

m=audio RTP/AVP 97 96 

c=IN IP6 5555: : aaa: bbb: ccc: ddd 

b=AS : 2 5 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap : 97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 2 

m=message 7654 TCP/MSRP 98 
C=IN IP6 5555: :aaa:bbb:CCC:fff 
a=accept- types : text/plain 



4. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

5. SIP EWITE request (intermediate EM CN subsystem entities to SCC AS) 

The SIP INVITE request is forwarded to the SCC AS as the result of the evaluation of iFC. 

6. Remote Leg Update 

The SCC AS identifies the session to be transferred using the STI. The SCC AS performs the Remote Leg 
update by sending the SIP re-INVITE request towards the Remote Leg. 

7. SIP re-EWITE request (SCC AS to intermediate IM CN subsystem entities)- See example in table A.8.2-7 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID headers from one side of the B2BUA to the other. In this example the SCC AS includes 
the contents of the Contact header from the received SIP INVITE request. The SIP re-INVITE request contains 
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the SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP INVITE request from 

the UE A (Step 3). 

Table A.8.2-7: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE < sip : user2_publicl@home2 . net ;gr=urn : uuid : 2ad8950e-4 8a5-4a74-8d99-ad76cc7f c74>; SIP/2 . 
Via: SIP/2. 0/UDP sccas.homel.net; branch=z9hG4bK332b33 . 3 ; 
Max-Forwards: 67 

Route: <scscf 1 . homel . net ; Ir > , <sip : scscf 2 . home2 . net ; lr> , <sip : pcscf 2 . visited2 . net ; lr> 
P-Asserted- Identity : "John Doe" <sip :userl_publicl@homel .net>, <tel : +l-237-555-llll> 

P-Access-Network-Info : IEEE-802 . lib 
Privacy: none 

P- Charging- Vector : icid-value= "AyretyU0dm+6O2IrT5tAFrbHLso=023 551024 " 
P-Charging-Function-Addresses : 

From: <sip : userl_publicl@homel . net> ; tag=1717777 

To: <tel:+l-237-555-2222>, tag=4321 

Call -ID: dcl4bltl0b3teghmlk50132 3 7 

Cseq: 111 INVITE 

Supported: precondition, lOOrel 

Contact : < sip : userl_publicl®homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a76 5 - 

00a0c91e6bf 6> ; +g . 3gpp . icsi -ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp 
Content-Type: application/sdp 
Content-Length: (...) 
v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : f f f 
s=t=0 

m=audio RTP/AVP 97 96 

c=IN IP6 5555: :aaa:bbb:ccc:ddd 

b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap : 97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 20 

m=message 7654 TCP/MSRP 98 
c=IN IP6 5555: :aaa:bbb:ccc:fff 
a=accept- types : text/plain 



8. SIP re-EWITE request (Intermediate EM CN subsystem entities to UE B) 

The intermediate IM CN subsystem entities forwards the SIP re-INVITE request to remote UE B. 
9-10: SIP 200 (OK) response (UE B to SCC AS via Intermediate EM CN subsystem entities) 

The UE B generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the SCC AS. 
1 1-12: SIP ACK request (SCC AS to UE B via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the remote UE B. 
13-14: SIP 200 (OK) response (SCC AS to UE A via Intermediate EM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request and forwards it to the SC UE A. 
15-16: SIP ACK request (SC UE A to SCC AS via Intermediate EM CN subsystem entities) 

The SC UE A generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the SCC AS 

17. Media paths between UE A and UE B 

The non-realtime media is using the new IP -CAN while the realtime media path is still over the old IP-CAN. 

18. SETUP message (SC UE A to Interworking entities) 

The SC UE sends the CS SETUP message with the STN as the called party number. 
NOTE 3: STN is a PSI DN used by the UE to request a session transfer towards the SCC AS. 
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19. SIP INVITE request (Interworking entities to Intermediate EM CN subsystem entities) -see example in 
Table A.8.2-19 

Table A.8.2-19: SIP INVITE request (interworking entities to intermediate IM CN subsystem entities) 



INVITE tel:+l-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mscl.homel.net; branch=z9hG4bKnashds7 
Max - Forwards : 7 

Route : <sip : icscf 1 . homel . net : 7531 ; Ir ; comp=sigcomp> 
P-Asserted-Identity : <tel: +l-237-555-llll> 

P- Charging- Vector : icid-value= "AyretyU0dm+6O2IrT5tAFrbHLso=023 551024 " ; orig- ioi=homel . net 
Privacy: none 

From: <tel: +1-237- 555 - 1111> ; tag=171828 
To: <tel : +l-237-555-2222> 
Call -ID: Cb03a0s09a2sdfglkj4903 3 3 
Cseq: 127 INVITE 

Supported: lOOrel, precondition 
Require: sec-agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; port=7531 

Contact : <sip : mgcf 2 . home2 . net ; gr> ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Accept: application/sdp, application/3gpp- ims+xml 

Content-Type: application/sdp 

Content-Length: (...) 



v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : eee 
s= 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 
t=0 

m=audio 3456 RTP/AVP 97 96 
b=AS : 2 5 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone -event 
a=maxpt ime : 2 



Request-URI: contains the IMRN, as obtained from CS networks signalling. 
SDP: The SDP contains preconfigured set of codecs supported by the MGW. 

20. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

21. SIP INVITE request (Intermediate IM CN subsystem entities to SCC AS) 

22. Remote Leg Update 

The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the Remote Leg. 

23. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) -see example in table A.8.2- 
23 

The SCC AS acting as a routing B2BUA generates a SIP INVITE request based upon the received SIP INVITE 

request and the information previously stored against this session and routes it towards UE B via the 
intermediate IM CN subsystem entities. In this example the SCC AS includes the contents of the Contact header 
from the received SIP INVITE request. 
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Table A.8.2-23: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE < sip : user2 publicl@home2 . net ;gr=urn : uuid : 2ad8950e-4 8a5-4a74-8d99-ad76cc7f c74> SIP/2 . 
Via: SIP/2. 0/UDP sccasl .homel .net;branch=z9hG4bKjias34r5 
Max-Forwards: 67 

Route: <sip : scscfl . homel . net : lr> 
P-Asserted-Identity : <tel: +l-237-555-llll> 

P- Charging- Function- Addresses : ccf = [5555: :b9 9:c88:d7 7:eeG] ; ccf = [5555: :a55 :b44 : c33 :d22] ; 

ecf= [5555: : If f : 2ee : 3dd : 4ee] ; ecf= [5555: : Saa : 7bb : 8cc : 9dd] 
P- Charging- Vector : icid-value= "AyretyU0dm+602IrT5tAFrbHLso=023 551024 " ; orig- 

ioi= " type3homel . net " 
Privacy: none 

From: <tel : +1-23 7 - 555 - 1111> ; tag=171828 
To: <tel : +l-237-555-2222>; tag=26545 
Call -ID: Cb0 3a0s09a2sdfglkj4 90333 
Cseq: 127 INVITE 

Supported: lOOrel, precondition 
Require: sec-agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; port=7531 
Contact : < sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 
00a0c91e6bf G> ; +g . 3gpp . icsi -ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Accept: application/sdp , application/3gpp- ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : eee 

s= 

t = 

m=audio 3456 RTP/AVP 97 96 
c=IN IP6 5555 :: aaa: bbb: ccc : eee 
b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 2 

m=message 7654 TCP/MSRP 98 
C=IN IP6 5555: :aaa:bbb:CCC:fff 
a=accept- types : text/plain 

24. SIP re-EWITE request (Intermediate IM CN subsystem entities to UE B) 

Intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE B. 

25. SIP 200 (OK) response (UE B to intermediate IM CN subsystem entities) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE B has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 

SDP answer indicates that the resources are available. 

26. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SIP re-INVITE request to 

the SCC AS in the originating network. 

27-28. SIP ACK request (SCC AS to UE B via IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request 
to the remote UE B. 

29-30. SIP 200 (OK) response (SCC AS to interworking entities via IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request, and forwards the SIP 200 (OK) 
response to the interworking entities. 

31. ISUP CONNECT message (interworldng entities to SC UE A) 

32. ISUP CONNECT Response message (SC UE A to interworking entities) 
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33-34. SIP ACK request (interworking entities to SCC AS via EM CN subsystem entities) 

The interworking entities generate the SIP ACK request to the SIP 200 (OK) response, and forward it to the SCC 
AS. 

35-36: SIP BYE request (SCC AS to SC UE A via intermediate EM CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the old IP-CAN, by sending a BYE request to the 
UE A. 

37-38. SIP 200 (OK) response (SC UE A to SCC AS via intermediate EM CN subsystem entities) 

Upon receiving the BYE request over the old IP-CAN, the SC UE A sends a SIP 200 (OK) response over the old 
IP-CAN to the SCC AS. Subsequentiy, the SC UE A relinquishes all resources pertaining to the old IP-CAN. 

39. Media paths between SC UE A and UE B 

Finally, the non-realtime media path is over the new IP-CAN and the realtime media is using the CS bearer. 

A.8.3 PS - PS in conjunction with PS - CS Access Transfer: CS to 
PS 

In this example, SC UE A has an ongoing multimedia session with remote UE B over IP-CAN#1 and CS bearer before 
access transfer. When SC UE connects to a new IP-CAN#2, it decides to transfer all the multimedia session over the 
new IP-CAN#2. 
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Figure A.8.3-1 : Signalling flow for PS - PS in conjunction with PS - CS Access Transfer: CS to PS 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalUng flow. 
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1. SC UE A has an ongoing multimedia session with remote UE B 

The non realmedia path is over old IP-CAN#1 and the realtime media path is over the CS bearer. The call has 
been anchored at the SCC AS which is in the HPLMN of originating SC UE A. The call leg over old IP-CAN#1 
is identified with "Call-ID= me03a0s09a2sdfgjkl491777", "Fromtag=64727891", and "To tag=774321". The UE 
A and UE B exchange media over the old IP-CAN, which is maintained while the SC UE A initiates the 
handover procedure. 

2. SC UE A connects to a new IP-CAN#2 

The SC UE A decides to transfer the multimedia session over the new IP-CAN#2. The UE A obtains an IP 
address that it will use for the signalling and media. It registers with the S-CSCF over the new IP-CAN using 
multiple registrations procedure. Depending on the UE A configuration, the discovery of the P-CSCF in the new 
IP-CAN may be needed. Based on the UE A and new IP-CAN capabihties, the UE A decides to use the same 
codec that was used over the old IP-CAN. The UE A reserves resources (e.g. QoS) in the new IP-CAN that will 
be needed for the signalling and transferred media, prior to sending the initial SIP INVITE request. 

3. SIP EVVITE request (SC UE A to intermediate IM CN subsystem entities)- see example in table A.8.3-3 

Upon sending the initial SIP INVITE request, the UE A is ready to receive the RTP packets either over the new 
IP-CAN or the old IP -CAN. The RTP packets may arrive over the new IP-CAN prior to the SC UE are receiving 
the SIP 200 (OK) response for the initial SIP INVITE request. 

Table A.8.3-3: SIP INVITE request (UE A to intermediate IM CN subsystem entities) 



INVITE tel :+l-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : f f f ] : 1357 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max- Forwards : 70 

Route : sip : pcscf 1 . homel . net : 7531 ; Ir ; comp=sigcomp> , <sip : origOscscf 1 . homel . net ; lr> 
P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 
P-Access-Network-Info : IEEE-802 . lib 
Privacy: none 

From: <sip : userl_publicl®homel . net > ; tag=171828 

To: <tel : +l-237-555-2222> 

Call -ID : Cb03a0s09a2sdfglkj 490237 

Cseq: 127 INVITE 

Supported: lOOrel; precondition, gruu, 199 
Require: sec-agree, replaces 
Proxy-Require: sec-agree 

Accept -Contact : * ; +g . 3gpp . icsi-ref= "urn%3Aurn- 7%3gpp- service . ims . icsi .mmtel " 
P- Preferred- Service : urn : urn- 7 : 3gpp- service . ims . icsi . mmtel 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; portl=7531 

Contact : <sip : userl_publicl@homel . net ; gr= urn : uuid : f 81d4f ae-7dec-lldO - a765 - 
00a0c91e6bf G> ; +g . 3gpp . icsi -ref = "urn%3Aurn-xxx%3gpp- 
service . ims . icsi . mmtel " ; +g . 3gpp . ics= "principal " ; 

Replaces: me03a0s0 9a2sdf gj kl491777 ; to-tag=774321 ; f rom-tag=64727891 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Accept: application/sdp; application/3gpp-ims+xml 

Content-Type: application/sdp 

Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : fff 
s= 

c=IN IP6 5555 :: aaa :bbb : ccc : fff 

t = 

m=audio 3456 RTP/AVP 97 96a=tcap:l RTP/AVPF 
a=pcfg:l t=l 
b=AS : 2 5 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 2 

m=message 7654 TCP/MSRP 98 
a=accept - types : text/plain 



Request-URI: Contains the static STI. 
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4. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

5. SIP INVITE request (intermediate EM CN subsystem entities to SCC AS) 

The SIP INVITE request is forwarded to the SCC AS as the result of the evaluation of iPC. 

6. Remote Leg Update 

The SCC AS identifies the session to be transferred using the STI. The SCC AS performs the Remote Leg 
update by sending the SIP re-INVITE request towards the Remote Leg. 

7. SIP re-EWITE request (SCC AS to intermediate EM CN subsystem entities)- See example in table A.8.3-7 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID headers from one side of the B2BUA to the other. In this example the SCC AS includes 
the contents of the Contact header from the received SIP INVITE request. The SIP re-INVITE request contains 
the SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP INVITE request from 
the UE A (Step 3). 

Table A.8.2-7: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE sip : user2_publicl@home2 . net ;gr=urn : uuid : 2ad8 950e-4 8a5-4a74-8d99-ad76cc7f c74 SIP/2 . 
Via: SIP/2. 0/UDP sccas.homel.net; branch=z9hG4bK332b33 . 3 ; 
Max- Forwards : 6 7 

Route: <scscf 1 . homel . net ; Ir > , <sip : scscf 2 . home2 . net ; lr> , <sip :pcscf 2 . visited2 . net ; lr> 
P-Asserted- Identity : "John Doe" <sip :userl_publicl@homel .net>, <tel : +l-237-555-llll> 

P-Access -Network- Info : IEEE- 8 02 . lib 
Privacy: none 

P- Charging- Vector : icid-value = "AyretyU0dm+6O2IrT5tAFrbHLso=023 551024 " 
P-Charging-Function-Addresses : 

From: <sip : userl_publicl@homel . net> ; tag=559812 
To: <tel:+l-237-555-2222>, tag=4321 
Call -ID: dcl4bltl0b3teghmlk50132 3 7 
Cseq: 111 INVITE 

Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lld0-a765- 
00a0c91e6bf 6> ; +g . 3gpp . icsi -ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Content -Type : application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : f f f 

s= 

c=IN IP6 5555: :aaa:bbb:ccc:fff 

t = 

m=audio 3456 RTP/AVPF 97 96 
b=AS : 2 5 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxpt ime : 2 

m=message 7654 TCP/MSRP 98 
a=accept - types : text/plain 



8. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B) 

The intermediate IM CN subsystem entities forwards the SIP re-INVITE request to remote UE B. 

9-10: SIP 200 (OK) response (UE B to SCC AS via Intermediate EM CN subsystem entities) 

The UE B generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the SCC AS. 

11-12: SIP ACK request (SCC AS to UE B via Intermediate EM CN subsystem entities) 
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The sec AS generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the remote UE B. 
13-14: SIP 200 (OK) response (SCC AS to UE A via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request and forwards it to the SC UE A. 
15-16: SIP ACK request (SC UE A to SCC AS via Intermediate IM CN subsystem entities) 

The SC UE A generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the SCC AS 

17. Media paths between UE A and UE B 

The multimedia is using the new IP-CAN. Resources used for signalling on the old IP-CAN#1 and CS bearer are 
not released. 

18-19. SIP BYE request (SCC AS to SC UE A via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg- that was using the old IP-CAN#1, by sending a SIP BYE request 
towards the SC UE A. 

20-21. SIP 200 (OK) response (SC UE A to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the SIP BYE request over the old IP-CAN#1, the SC UE A sends a SIP 200 (OK) response over 
the old IP-CAN. Subsequently, the UE-1 relinquishes all resources pertaining to the old IP-CAN. 

22-23. SIP BYE request (SCC AS to interworking entities via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the CS bearer, by sending a BYE request. 
24-25. ISUP Message 

Upon receiving the DISCONNECT request, the SC UE A relinquishes aU resources pertaining to the CS bearer. 
26-27. SIP 200 (OK) response (Interworking entities to SCC AS via intermediate IM CN subsystem entities) 
28. Media patlis between UE A and UE B 

The multimedia session is using the new IP-CAN#2. 

A.9 Signalling flows for media adding/deleting for access 
transfer 

A.9.1 Introduction 

The signalling flows for media adding/deleting demonstrate how the media of a multimedia session is added or deleted. 
The following signalling flow is included: 

- subclause A.9. 2 shows an example when the non-realtime media of a multimedia session over the IP-CAN is 
removed. 

A.9. 2 Remote End Initiation case - Removing media from split CS 
and PS sessions 

As a precondition the SC UE A has a CS call and IMS multimedia session with the remote end after session transfer in a 
manner that more than one session are presented to UE B as one IMS session by the SCC AS. 
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SC UE A is on an active multimedia session with UE B. Call is anchored at SCC AS. 
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Figure A.9.2-1 : Remote End Initiation case - Removing media from split CS and PS sessions 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalhng flow. 
1. SC UE A has an ongoing multimedia session with remote UE B 

The call has been anchored at the SCC AS which is in the HPLMN of originating SC UE A. 
Table A.9.2-1 shows an example of the SDP offer from SC UE A to remote UE B. 
NOTE 2: To show how the media is removed, only the SDP offer is shown in this example. 
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Table A.9.2-1 : SIP INVITE request (SC UE A to intermediate IM CN subsystem entities) 



INVITE tel:+l-237-555-2222 SIP/2.0 
Via : 

Max- Forwards : 
Route : 

P- Asserted- Identity: 

P- Charging- Vector ; 

P- Access -Network- Info: 

Privacy : 

From : 

To : 

Call-ID: 
Cseq : 

Supported : 
Require : 
Proxy-Require : 
Security-Verify : 
Contact : 
Allow: 
Accept : 
Content-Type : 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : CCC : ddd 
s = 

c=IN IP6 5555 :: aaa : bbb : CCC : ddd 
t = 

m=message 7654 TCP/MSRP 98 
a=accept- types : text/plain 



2. SIP re-EWITE request (UE B to intermediate EM CN subsystem entities)- See example in table A.9.2.-2 

The remote UE B decides to remove the non-realtime media from the multimedia session. It uses standard IMS 
procedures to remove one or more PS media from the session. 
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Table A.9.2-2: SIP re-INVITE request (UE B to intermediate IM CN subsystem entities) 



INVITE < sip : userlpubliclohomel . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6> SIP/2.0 
Via: SIP/2. 0/UDP sccasl .homel .net;branch=z9hG4bKjias34r5 
Max-Forwards: 67 

Route: <sip : scscfl . homel . net : lr> 
P-Asserted-Identity : <tel: +l-237-555-2222> 

P- Charging- Function- Addresses : ccf = [5555: :b9 9:c88:d7 7:eeG] ; ccf = [5555: :a55 :b44 : c33 :d22] ; 

ecf= [5555: : If f : 2ee : 3dd : 4ee] ; ecf= [5555: : Saa : 7bb : 8cc : 9dd] 
P- Charging- Vector : icid-value= "AyretyU0dm+602IrT5tAFrbHLso=023 551024 " ; orig- 

ioi= " type3homel . net " 
P-Access-Network-Info : 
Privacy: none 

From: <tel: +1-23 7-555-2222; gr=hdg7777ad7af IzigSsf 7> ; tag=171828 

To: <tel : +l-237-555-llll> 

Call -ID : Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: lOOrel, precondition 
Require: sec-agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; port=7531 
Contact : < sip : user2_publicl®home2 . net ;gr=urn : uuid : 2ad8 95 0e-4 8a5-4a74-8d99- 

ad7 6cc7f c74 > ; +g . 3gpp . icsi -ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Accept: application/sdp , application/3gpp-ims+xml 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

0=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : CCC : ddd 
s= 

c=IN IP6 5555 : :aaa:bbb:ccc:ddd 

t = 

m=audio 3456 RTP/AVP 97 96 
b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 20 
m=message TCP/MSRP 98 
a=accept- types : text/plain 



3. SIP re-EWITE request (Intermediate EM CN subsystem entities to SCC AS) 

4-5. SIP 200 (OK) response (SCC AS to UE B via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the remote 
UEB. 

6-7: SIP ACK request (UE B to SCC AS via Intermediate EM CN subsystem entities) 

The UE B generates the SIP ACK request to the SIP SIP 200 (OK) response and forwards it to the SCC AS. 

8-9: SIP BYE request (SCC AS to SC UE A via intermediate EM CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the IP-CAN, by sending a SIP BYE request to the 
UEA. 

10-11. SIP 200 (OK) response (SC UE A to SCC AS via intermediate EM CN subsystem entities) 

Upon receiving the BYE request over the IP-CAN, the SC UE A sends a SIP 200 (OK) response over the IP- 
CAN to the SCC AS. Subsequently, the SC UE A relinquishes all resources pertaining to the IP-CAN. 

12. Media paths between SC UE A and UE B 

Finally, the non-realtime media path over the IP-CAN is removed. 
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A.1 Signalling flows for target UE discovery for inter-UE 
transfer 

A.1 0.1 Introduction 

A.I 0.2 Subscription to registration event 
A.1 0.3 Discovery of target UE capabilities 

A.1 1 Signalling flows for Inter-UE Transfer without 
establishment of Collaborative Session 

A.1 1.1 Introduction 

The signalling flows in the subclause demonstrate how a UE-1 can initiate the inter UE transfer of the complete session 
without Collaborative Session establishment. 

The example assumes that the UE-1 and UE-2 are under the control of the same subscriber. 

A.1 1 .2 Complete transfer in services defining only originating 
session set up in UE 

In the example flow at the figure A.1 1.2-1, UE-1 has an ongoing multimedia session with UE-3 anchored at SCC AS. 
The session is estabUshed using an IMS communication service identified by ICSI urn:um-7:3gpp-service.ims.icsi.iptv 
which is an IMS communication service which defines originating session set up in the UE only. 
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Figure A.1 1 .2-1 : Signalling flow for inter UE transfer without Collaborative Session establishment 



NOTE 1: For clarity, the SIP 100 (Trying) responses and the SIP NOTIFY requests earring the message/sipfrag 
with SIP 100 (Trying) response are not shown in the signalling flow. 

1. UE-1 is in session with UE-3 

There is a multimedia session comprising audio and video media between the UE-1 and the remote UE-3 
anchored at SCC AS. The session was established using IMS communication service identified by ICSI urn:iu-n- 
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7:3gpp-service.ims.icsi.iptv. The dialog identifier of the session is AB03a0s09a2sdfglkj490333, remote- 
tag=Afgsdfg45, local-tag=U188gg. 

2. SIP REFER request initiating the inter UE transfer to UE-2 (UE-1 to Intermediate IM CN subsystem 
entities) - see example in table A. 11. 2-2 

Table A.1 1.2-2: SIP REFER request (UE-1 to Intermediate IM CN subsystem entities) 



REFER sip luserohomel . net ; gr=urn : uuid : f 8 Id4fae-7dec-lld0-a76 5 -222222222222 SIP/2.0 
Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max-Forwards: 70 

P- Preferred- Identity : <sip : userohomel . net > 
From : <sip : userohomel . net > ; tag=17182 8 

To: <sip:user@homel . net ; gr=urn : uuid : f 8 ld4fae-7dec- Ild0-a76 5 -222222222222 > 
Call-ID: Asdasd231233 
Cseq: 4127 REFER 

Contact : <sip : userohomel . net ; gr=gr=urn : uuid : f 8 ld4fae-7dec- Ild0-a76 5 -111111111111 > 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Length: 

Refer-To : <sip : remoteuser@home2 . net ; gr=urn : uuid : f 81d4fae-7dec- Ild0-a765- 333333333333 ?Target- 
Dialog=AB03a0s09a2sdf glkj 490333 %3Bremote-tag=Af gsdfg45%3Blocal - 

tag=UlBBggS:Require=tdialogSeP-Pref erred-Service=urn:urn-7 : 3gpp-service . ims . icsi . iptv&Accept- 
Contact=* %3b+g . 3gpp . icsi -ref %3d%2 2urn%2 53Aurn- 7%2 53gpp-service . ims . icsi . iptv%2 2 > 



Request-URI: contains the GRUU of the UE-2 

Refer-To: contains the remote target used in the session with UE-3, i.e. GRUU of the UE-3 together with 
Target-Dialog URI header field containing the dialog identifier of the session with UE-3, Require URJ header 
field containing the "tdialog" and P-Preferred-Service and Accept-Contact URI header fields containing the ICSI 
of the service to be requested by UE-2. 

Contact: contains the GRUU of the UE-1 

Editor's note: it is FES whether and how to indicate the media to be transferred 

3. Evaluation of initial filter criteria 

The S-CSCF evaluates originating initial filter criteria for the served user and as a result routes the SIP REFER 
request towards the SCC AS. 

4. SIP REFER request (Intermediate IM CN subsystem entities to SCC AS) 

5. The SCC AS authorizes the request and if authorization is passed successfully, the SCC AS forwards the 
SIP REFER request further 

6. -7. SIP REFER request (SCC AS to UE-2) 

8.-11. SIP 202 response to the SIP REFER request (UE-2 to UE-1) 

12. SIP INVITE request (UE-2 to intermediate IM CN subsystem entities) - see example in table A.11.2-12 
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Table A.11.2-12: SIP INVITE request (UE-1 to Intermediate IM CN subsystem entities) 



INVITE sip : remoteuser@home2 . net ; gr=urn : uuid : f81d4fae-7dec-lldO-a765- 333333333333 SIP/2 . 
Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : f f f ] : 1357 ; comp=sigcomp ;branch=z9hG4bKjiashds7 
Max-Forwards: 70 

P- Preferred- Identity : <sip : userohomel . net > 
From : <sip : userohomel . net > ; tag=17182 8 

To : <sip : remoteuser@home2 . net ; gr=urn :uuid: f 8 ld4fae- 7dec- lldO -a76 5 -333333333333 > 
Call-ID: tq34gasgaegr 
Cseq: 4127 INVITE 

Contact : <sip : userohomel . net ;gr=urn : uuid : f 8 ld4fae-7dec- lldO-a7S 5 -222222222222 > 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Target-Dialog: AB03a0s09a2sdf glkj490333 ; remote -tag=Afgsdfg4 5 ; local-tag=U188gg 

Require: tdialog 

Content-Type: application/sdp 

Content-Length: (...) 

Supported: lOOrel, precondition 

P- Preferred- Service : urn : urn- 7 : 3gpp- service . ims . icsi . iptv 

Accept -Contact : * ; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi . iptv" 
v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : fff 
s= 

c=IN IP6 5555 :: aaa :bbb : ccc : fff 
t = 

m=audio 3456 RTP/AVP 97 96 
a = tcap : 1 RTP/AVPF 
a=pcfg:l t=l 
b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone-event 
a=maxptime : 2 

m=video 3400 RTP/AVP 98 99 
b=AS : 75 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



Request-URI: set to the URI in the Refer-To of the received SIP REFER request 
Contact: contains the GRUU of the UE-2 

Target-Dialog: set to the value of the Target-Dialog URI header field of the URI in the Refer-To of the 
received SIP REFER request 

Require: set to the value of the Require URI header field of the URI in the Refer-To of the received SIP 
REFER request 

P-Preferred-Service: set to the value of the P-Preferred-Service URI header field of the URI in the Refer-To 
of the received SIP REFER request 

Accept-Contact: set to the value of the Accept-Contact URI header field of the URI in the Refer-To of the 
received SIP REFER request 

13. Evaluation of initial filter criteria 

The S-CSCF evaluates originating initial filter criteria for the served user and as a result routes the SIP INVITE 

request towards the SCC AS. 

14. SIP INVITE request (Intermediate IM CN subsystem entities to SCC AS) 

15. Remote Leg Update 
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Based on the STI in the Target-Dialog header field the SCC AS detects that the inter UE tranfer is being 
attempted and performs the Remote Leg update by sending the SIP re-INVITE request towards the Remote Leg. 

16-18. SIP re-INVITE request (SCC AS to UE-3 over intermediate IM CN subsystem entities) 

The SCC AS acting as a routing B2BUA generates a SIP re-INVITE request based upon the received SIP 
INVITE request and the information previously stored against this session and routes it towards UE-3 via the 
intermediate IM CN subsystem entities. 

19-21. SIP 200 (OK) response (UE-3 to intermediate IM CN subsystem entities) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE-3 has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

22-24. SIP ACK request (SCC AS to UE-3 via intermediate IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request 
to the remote UE-3. 

25-26. SIP 200 (OK) response (SCC AS to UE-2 via intermediate IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request, and forwai'ds the SIP 200 (OK) 
response towards the UE-2. 

27-28. SIP ACK request (UE-2 to SCC AS via intermediate IM CN subsystem entities) 

The UE-2 generate the SIP ACK request to the SIP 200 (OK) response, and forward it to the SCC AS. 

29. Media and IMS service control paths: 

The media path is now established between UE-2 and UE-3 and the IMS service control between UE-2 and SCC 
AS. 

30-33. SIP NOTIFY request (UE-2 to UE-1 over intermediate IM CN subsystem entities and SCC AS) 

The UE-2 generate the SIP NOTIFY request carrying the message/sipfrag body and send it towards UE-L 

34-37. SIP 200 OK response to the SIP NOTIFY request (UE-1 to UE-2 over intermediate IM CN subsystem 
entities and SCC AS) 

38-39: SIP BYE request (SCC AS to UE-1 via intermediate IM CN subsystem entities) 

The SCC AS terminates the source access leg by sending a BYE request to the UE-L 

40-41. SIP 200 (OK) response (UE-1 to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the BYE request, the UE-1 sends a SIP 200 (OK) response to the SCC AS. Subsequently, the 
UE-1 relinquishes all resources pertaining to the session. 

A.1 1 .3 Complete transfer in services defining terminating session 
set up in UE 

Editor's note: Complete transfer in services defining terminating session set up in UE is FFS 
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A.1 2 Signalling flows for establishment of collaborative 
session for inter-UE transfer 

A. 12.1 Introduction 

A. 12.2 Collaborative session establishment by transferring media 
A. 12.3 Collaborative session establishment with new media 

There is an existing session with audio between controller UE, UE-1, and remote UE. The controller UE estabhshes a 
collaborative session by adding a video media component to the controllee UE, UE-2. 
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Figure A.1 2.3: Controller UE establishes a collaborative session by adding a new media on controllee 

UE 



1-2. SIP REFER request (from UE-1 to SCC-AS) 
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The controller UE, UE-1 sends a REFER request to the SCC AS containing a Refer-To header containing the GRUU of 
controllee UE, UE-2 and a body parameter containing an m line for audio set to zero and an m line for video with the 
port number set to the discard port number "9" since the port number is unknown. The REFER request also includes a 
Target-dialog header field containing the details fo the dialog for the existing session between controller UE, UE-1 and 
the remote UE. 



Table A.I 2.3-1 SIP REFER request (UE-1 to SCC-AS) 



REFER sip : scc-asohomel . net SIP/2.0 




Via : 




To : sip : SCC -asohomel . net ; tag=13 579 




From: sipiuserl pubiciohomel . net ; tag=24680 




Call -ID: Cb03a0s09a2sdfglkj 490333 




CSeq: 93809824 REFER 




Max-Forwards: 70 




P- Preferred- Identity : 




Refer-To: <sip:userl public2®home2 . net ; gr=urn : uuid 


f 81d4f ae-7dec-lldO-a762- 


00a0c91e6bf 6?body=m%3Daudio%2 00%2 0RTP%2FAVP%2 096%0Dm%3Dvideo%2 09%2 0RTP%2FAVP%2 09B%2 099> 


Require: target-dialog 




Target-dialog: cb03a0s09a2sdfglkj 13579 ; remote-tag= 


abcdef; local-tag=123456 


Contact: <sip:userl publicl@homel.net; gr=urn:uuid 


f 81d4f ae-7dec-lld0-a765-00a0c91ewxyz> 


Allow : 




Accept: message/sipf rag 




Content-Length: 





3-4. SIP 202 (Accepted) response (from SCC AS to UE-1) 

SCC-AS sends SIP 202 (Accepted) response to controller UE-1 as response to the SIP REFER request. 
5-6. SIP NOTIFY request (from SCC AS to UE-1) 

SCC-AS sends a SIP NOTIFY request to UE-1 notifying implicit subscription to the SIP REFER request. 

Table A.I 2.5-2 SIP NOTIFY request (SCC-AS to UE-1) 



NOTIFY 
Via : 

To: sip : userl pubiclahomel . net ; tag=13579 
From: sip : scc-asOhomel . net ; tag=24680 
Call-ID^ 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact: sip: scc-as@homel.net 
Allow: 

Event : refer 

Subscript ion- St ate : active ; expires=3600 
Content-Type : message/sipf rag; version=2 . 
Content-Length: (...) 

SIP/2.0 100 Trying 



7-8. SIP 200 (OK) response (from UE-1 AS to SCC-AS) 

The controller UE, UE-1, acknowledges the SIP NOTIFY request by sending SIP 200 (OK) response to SCC-AS. 
9-10. SIP INVITE request (from SCC-AS to UE-2) 

SCC-AS sends SIP INVITE request to the controllee UE, UE-2, adding video media and establishing collaborative 
session.Since the URI parameters indicates that the port number for video m-line is set to the discard port number "9", 
the SCC AS realizes that the port number of the remote UE is unknown and therefore adds an a-line to inactive in SDP 
offer to prevent the controllee UE sending media to the remote UE. The SDP offer contains the audio media component 
on controller UE, UE-1 set to zero. The INVITE request contains a Referred-By header containing the identity of UE-1. 
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Table A.I 2.9-3 SIP INVITE request (SCC-AS to UE-2) 



INVITE sip :user2_publicl®homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - OaOc91e6bf 6 SIP/2.0 
Via : 

Record-Route : sip : scc-as@homel . net 

To: sip : user2_pubicl(ahomel . net ; 

From : sip : user3_pubic3@home3 . net ; tag=acegi 

Call-ID: 

CSeq: 

Max- Forwards : 

P-Asserted- Identity : "remote user" sip : user3_pubic3®home3 . net 
Require : 

Ref erred-By : sip : userl_pubicl@homel . net 

Contact : sip : user3_public3@home3 . net ; gr=urn : uuid : f 81d4f ae- 17oct- llal-a678 - 0054c91eabcd 
Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 
s = - 
t = 

m=audio RTP/AVP 
m=video 9 RTP/AVP 98 99 
a=inactive 
c=123 . 112 .67.87 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



Editor's note: The value of c-line is FFS. 
11-12. SIP 200 (OK) response (from UE-2 to SCC-AS) 

The controllee UE, UE-2, acknowledges the INVITE request by sending SIP 200 (OK) reqponse to SCC-AS. 

Table A.12.3-11 SIP 200 (OK) response (UE-2 to SCC-AS) 



SIP/2.0 200 OK 
Via : 

To: sip : user2 pubicl@homel . net ; tag=xyzwv 
From : sip : user3_pubic3@home3 . net ; tag=acegi 
Call-ID: 
CSeq: 

P- Preferred- Identity : 

Contact : sip : user 1 public2®home2 . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - OaOc91e6bf 6 
Allow: INVITE, PRACK, UPDATE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 145.23.77.88 
s = - 

t=a 

m=audio RTP/AVP 
m=video 9 RTP/AVP 98 
a=inactive 
c=145 .23.77.88 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 



13-14. SIP ACK request (from SCC-AS to controllee UE) 

SCC-AS sends SIP ACK request to the remote UE. 

15-16. SIP NOTIFY request (from SCC-AS to conroUer UE, UE-1) 

SCC-AS sends SIP NOTIFY request to controller UE, UE-1 to inform about the success status of the inter- UE transfer. 
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Table A.I 2.3-1 5 SIP NOTIFY request (SCC-AS to UE-1) 



NOTIFY 
Via : 

To: sip : userl_pubicl@homel . net ; tag = 13579 
From : sip : scc-asohomel . net ; tag=24680 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact: sip: scc-as®homel . net 
Allow: 

Event : refer 

Subscription-State : terminated; reason=noresource 
Content-Type: message/sipf rag ;version=2.0 
Content-Length: (...) 

SIP/2.0 200 OK 

Content-Type: application/sdp 
m=audio RTP/AVP 
m=video 9 RTP/AVP 98 99 
c=145 .23.77.88 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 



17-18. SIP 200 (OK) response (from controller UE to SCC-AS) 

The conti-oller UE acknowledges the NOTIFY request by sending SIP 200 (OK) response to SCC-AS. 
19-20. SIP re-INVITE request (from SCC-AS to remote UE) 

SCC-AS sends SIP re-INVITE request to the remote UE. 

Table A.I 2.3-1 9 SIP re-INVITE request (SCC-AS to remote UE) 



INVITE sip:user3 public3(ahome3 . net ; gr=urn : uuid : f 81d4f ae-17oct-llal-a678-0054c91eabcd SIP/2 . 
Via : 

To : sip : user3_pubic3@home3 . net ; tag=66666 
From : sip : userl_pubicl@homel . net ; tag=33333 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact : sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 00a0c91ewxyz 
Allow : 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.45.67.89 
s = - 
t = 

m=audio 1300 RTP/AVP 96 97 
C=IN IP4 123 .45.67.89 
b=AS : 2 5 . 4 
a=rtpmap:96 AMR 

a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:97 telephone-event 

a=maxptime : 2 

m=video 1302 RTP/AVP 98 

C=IN IP4 145 .23.77.88 

b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 



21-22. SIP 200 (OK) response (from remote UE to SCC-AS) 

The remote UE acknowledges the SIP re-INVITE request by sending SIP 200 (OK) response to the SCC-AS. 
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Table A.I 2.3-21 SIP 200 (OK) response (remote UE to SCC-AS) 



SIP/2.0 200 OK 

Via : 

To : 

From : 

Call-ID: 

CSeq: 

P- Asserted- Identity : 

Contact : sip : user3_pubic3®home3 . net ; gr=urn : uuid : f 81d4f ae- 17oct- llal-a678 - 0054c91eabcd 
Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 
s = - 

c=IN IP4 123.112.67.87 
t = 

m=audio 3000 RTP/AVP 96 97 
b=AS : 25 . 4 
a=rtpmap:96 AMR 

a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:97 telephone-event 

a=maxptime : 2 

m=video 3002 RTP/AVP 98 

b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 



23-24. SIP ACK request (from SCC-AS to remote UE) 

SCC-AS sends SIP ACK request to the remote UE. 
25-26. SIP UPDATErequest (from SCC-AS to UE-2) 

Since the controllee UE, UE-2 inidcated in the Allow header field support for SIP UPDATE method the SCC-AS sends 
a SIP UPDATE request to the controllee UE, UE-2 to inform controllee UE about the port number for the video media 
component of the remote UE. The SCC AS add an a-line set to active in the SDP offer. 

NOTE: Any other changes such as IP address of the remote UE in case remote UE uses different IP addresses for 
different media would also be updated in the SIP UPDATE request. 

Table A.12.3-25 SIP UPDATE request (SCC-AS to UE-2) 



UPDATE sip :userl public2@home2 . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 0a0c91e6bf 6 SIP/2.0 

Via : 

To : 

From : 

Call-ID: 

CSeq: 

Contact : sip : user3_public3@home3 . net ; gr=urn : uuid : f 81d4f ae- 17oct- llal-a678 - 0054c91eabcd 
Allow : 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.45.67.87 
s=- 

C=IN IP4 123.45.67.87 

t = 

m=audio RTP/AVP 96 97 
m=video 3002 RTP/AVP 98 
b=AS : 75 
a=active 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 



23-24. SIP 200 (OK) response (from controllee UE to SCC-AS) 
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Table A.1 2.3-23 SIP 200 (OK) response (UE-2 to SCC-AS) 



olF/Z.U ZUU Uis. 




via : 




To : 




From : 




Call-ID: 




CSeq: 




Contact: sipiuserl public2@home2 


net;gr=urn:uuid: f 81d4f ae- 7dec- lldO -a765 - 00a0c91e6bf 6 


Allow: 




Content-Type: application/sdp 




Content-Length: (...) 




v=0 




o=- 1027933615 1027933615 IN IP4 


145 .23.77.88 


s = - 

t = 




m=audio RTP/AVP 




m=video 1302 RTP/AVP 98 




c=145 .23.77.88 




b=AS : 75 




a=active 




a=rtpmap:98 H263 




a=fmtp:98 prof ile-level-id=0 





27-28. SIP ACK request (from SCC-AS to controUee UE) 

SCC-AS sends SIP ACK request to controllee UE to acknowledge. 
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A.1 3 Signalling flows for media transfer within 
collaborative session for inter-UE transfer 

A. 13.1 Introduction 

A.I 3.2 Controller UE initiated media transfer from controller UE to 
controllee UE 
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Figure A.1 3.2: Controller UE transfers a media on controllee UE 

1-2. SIP REFER request (SIP REFER request from UE-1 to SCC-AS) 

There is an existing session with audio and video between controller UE, UE-1 (123.45.67.89), and remote UE 
(132.54.76.98). The video component is unidirectional from the remote UE to the controller UE, UEl. The Controller 
UE attempts to transfer the video portion of this session to the controUee UE, UE-2. 
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Table A.1 3.2-1 SIP REFER request (UE-1 to SCC-AS) 



REFER sip : scc-asohomel . net SIP/2.0 
Via : 

To: sip : scc-as@homel . net ; tag= 24680 

From: sip:userl pubicl@homel.net ; tag=13579 

Call -ID: Cb03a0s09a2sdfglkj 490333 

CSeq: 93809824 REFER 

Max-Forwards: 70 

P- Preferred- Identity : 

Refer- To : <sip : userl_public2@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a76 5 - 

00a0c91e6bf 6?body=m%3Dvideo%2 03 002%2 0RTP%2FAVP%2 098%2 099> 
Require: target-dialog 

Target -dialog: cb0 3a0s0 9a2sdf glkj 321576 ; remote- tag=abcdef ; local-tag=12 34 5 6 

Contact : <sip : userl_pubicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 00a0c91ewxyz> 

Accept: application/sdp, message/sipf rag 

Content-Length: 



Editor" s note: The use of URI parameters for inter-UE transfer is still under review. 
3-4. SIP 202 (Accepted) response (from SCC AS to UE-1) 

SCC-AS sends SIP 202 (Accepted) response to controller UE-1 as response to SIP REFER request. 
5-6. SIP NOTIFY request (from SCC AS to UE-1) 

SCC-AS sends SIP NOTIFY request to UE-1 to notify implicit subscription to the SIP REFER request results. 

Table A.I 3.2-2 SIP NOTIFY request (SCC-AS to UE-1) 



NOTIFY 
Via : 

To: sip : userl pubicl@homel . net ; tag =24680 
From: sip : scc-asOhomel . net ; tag=13579 
Call-ID^ 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact: sip: scc-as@homel.net 
Allow: 

Event : refer 

Subscript ion- St ate : active ; expires=3600 
Content-Type: message/sipf rag ; version=2 . 
Content-Length: (...) 

SIP/2.0 100 Trying 



7-8. SIP 200 (OK) response (from UE-1 AS to SCC-AS) 

The controller UE, UE-1, acknowledges the SIP NOTIFY request by sending SIP 200 (OK) response to SCC-AS. 
9-10. SIP INVITE request (from SCC-AS to UE-2) 

SCC-AS sends SIP INVITE request to the controUee UE, UE-2, to transfer video media. 

Editor" s Note: It is ffs how the controller UE signals what media are to be transferred when the SDP media order 
is different in controller UE and controllee UE. Table A. 13.2-3 SIP INVITE request (SCC-AS to UE-2) 
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INVITE sip :userl_public2@homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2.0 
Via : 

To: sip : userl_pubic2@homel . net ; 

From: sip : scc-asohomel . net ; tag=12486 

Call-ID^ 

CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact : 

Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 
s = - 

C=IN IP4 123.112.67.87 
t = 

m=video 3002 RTP/AVP 98 99 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



11-12. SIP 200 (OK) response (from UE-2 to SCC-AS) 

The controllee UE, UE-2, acknowledges the SIP INVITE request by sending SIP 200 (OK) response to SCC-AS. 

Table A.13.2-4 SIP 200 OK response (UE-2 to SCC-AS) 



SIP/2.0 200 OK 
Via : 

To: sip:userl pubic2@homel.net ; tag = xyzwv 
From: sip : scc-as@homel . net ; tag = 12486 
Call-ID^ 
CSeq: 

P- Preferred- Identity : 

Contact : sip : userl_pubic2@homel . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 
Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 145.23.77.88 
s = - 

c=145 .23.77.88 
t = 

m=video 1302 RTP/AVP 98 99 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



13-14. SIP re-INVITE request (from SCC-AS to remote UE) 

SCC-AS sends SIP re-INVITE request to the remote UE. 
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Table A.I 3.2-5 SIP INVITE request (SCC-AS to remote UE) 



INVITE sip:user3 public3@home3 .net SIP/2.0 
Via : 

To: sip : user3_pubic3@home3 . net ; tag = 66666 
From: sip : scc-asohomel . net ; tag=33333 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact : sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a76 5 - OaOc91ewxyz 
Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.45.67.89 
s = - 
t = 

m=audio 1300 RTP/AVP 96 97 
C=IN IP4 123 .45.67.89 
b=AS : 2 5 . 4 
a=rtpmap:96 AMR 

a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:97 telephone-event 
a=maxptime : 2 

m=video 1302 RTP/AVP 98 99 
C=IN IP4 145 .23.77.88 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



15-16. SIP 200 (OK) response (from remote UE to SCC-AS) 

The remote UE acknowledges the SIP re-INVITE request by sending SIP 200 (OK) response to SCC-AS. 

Table A.I 3.2-6 SIP 200 (OK) response (remote UE to SCC-AS) 



SIP/2.0 200 OK 

Via : 

To : 

From : 

Call-ID: 

CSeq: 

P- Asserted- Identity : 

Contact : sip : user3_pubic3®home3 . net 
Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 
s = - 

c=IN IP4 123.112.67.87 
t = 

m=audio 3000 RTP/AVP 96 97 
b=AS : 25 . 4 
a=rtpmap:96 AMR 

a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:97 telephone -event 
a=maxptime : 2 

m=video 3002 RTP/AVP 98 99 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



17-18. SIP ACK request (from SCC-AS to remote UE) 

SCC-AS sends SIP ACK request to the remote UE. 
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19-20. SIP ACK request (from SCC-AS to controUee UE; UE-2) 

SCC-AS sends SIP ACK request to the remote UE. 

21-22. SIP re-EWITE request (from SCC-AS to controller UE; UE-1) 

SCC-AS sends SIP re-INVITE request to the controller UE. 

Table A.1 3.2-7 SIP INVITE request (SCC-AS to UE-1) 



INVITE sip:userl_publicl®homel .net SIP/2.0 

Via: 

To: 

From : 

Call-ID: 

CSeq: 

Max- Forwards : 

P- Asserted- Identity: 

Require : 

Contact : 

Allow: 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s=- 

C=IN IP4 132.54.76.98 
t = 

m=audio 2 000 RTP/AVP 96 97 

b=AS:25.4 

a= r tpmap : 9 6 AMR 

a=fmtp:96 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:97 telephone-event 

a=maxpt ime : 2 

m=video RTP/AVP 98 99 

a=sendonly 

a=rtpmap:98 H2 63 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



23-24. SIP 200 (OK) response (from UE-1 to SCC-AS) 

The controller UE acknowledges the SIP re-INVITE request by sending SIP 200 (OK) response to SCC-AS. 
25-26. SIP ACK request (from SCC-AS to UE-1) 

SCC-AS sends SIP ACK request to the controllel UE, UE-1 in response to SIP 200 (OK) response. 
27-28. SIP NOTIFY request (from SCC-AS to conroUer UE, UE-1) 

SCC-AS sends SIP NOTIFY request to controller UE, UE-1 to inform about the success status if the inter-UE transfer. 
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Table A.1 3.2-8 SIP NOTIFY request (SCC-AS to UE-1) 



NOTIFY 
Via : 

To: sip:userl pubicl@homel.net ; tag=24680 
From: sip : scc-as@homel . net ; tag=13579 
Call-ID^ 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact: sip: scc-as®homel . net 
Allow: 

Event : refer 

Subscription-State : terminated; reason=noresource 
Content-Type: message/sipf rag ;version=2.0 
Content-Length: (...) 

SIP/2.0 200 OK 

m=video 1302 RTP/AVP 98 99 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



Editor" s Note: It is ffs if content-type header with SDP is needed in the body of the SIP NOTIFY request. 
29-30. SIP 200 (OK) response (from controller UE to SCC-AS) 

The remote UE acknowledges the SIP NOTIFY request by sending SIP 200 (OK) response to SCC-AS. 



A.1 3.3 Controller UE initiated media transfer from controllee UE to 
another controllee UE 



A. 14 Signalling flows for release of collaborative session 
for inter-UE transfer 



A. 14.1 Introduction 

The signalling flows for release of Collaborative Session demonstrate how the session is released by the Controller UE 
or by the remote party UE. The following signalling flow is included: 

subclause A. 14.2 shows an example where the Controller UE initiates release of a Collaborative Session. It 
demonstrates how the service control signalling and media path between the Controller UE and remote party UE 
and the media path between the Controlee UE and the remote party are released as a result of the session release; 
and 

- subclause A. 14.3 shows an example where the remote party UE initiates release of a Collaborative Session. 



A.1 4.2 Controller UE releases collaborative session 

In this example, session release is initiated by the Controller UE (UE 1), which is involved in the Collaborative Session 
with UE 2 and the remote party UE (UE 3). The SCC AS ensures that all Controlee UEs involved in the Collaborative 
Session receive a request for session release in order to completely release the session ongoing with the remote party 
UE. 
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Figure A.1 4.2-1 : Release of Collaborative Session initiated by Controller UE 

1. Collaborative Session currently exists in a dialog with UE 3 

A Collaborative Session involving UE 1 and UE 2 exists in a dialog with UE 3. Media paths exist between UE 1 
and UE 3 and between UE 2 and UE 3. In this scenario, UE 1 is the Controller UE in the Collaborative Session 
and thus maintains service control signalUng with the SCC AS. 

2-3. SIP BYE request (UE 1 to SCC AS via intermediate IM CN subsystem entities) 

UE 1, acting as the Controller UE, initiates session release by sending a SIP BYE request towards the SCC AS. 
There is no Inter UE transfer specific content in the BYE request. 

4-6. SIP BYE request (SCC AS to UE 3 via intermediate IM CN subsystem entities) 

The SCC AS routes the SIP BYE request to UE 3 indicating to the remote party UE that that the Conti-oUer UE 
requests that the session is to be released. 

7-9. SIP 200 (OK) response (UE 3 to SCC AS via intermediate EM CN subsystem entities) 

UE 3 responds to the received SIP BYE request with a SIP 200 (OK) response. 

10-11. SIP BYE request (SCC AS to UE 2 via intermediate IM CN subsystem entities) 

The SCC AS, acting as a routing B2BUA, sends a SIP BYE request towards UE 2 to release the dialog it is 
involved in with UE 3 via the Collaborative Session. There is no Inter UE transfer specific content in the BYE 

request. 

NOTE 1: The SIP BYE request to UE 2 (step 10) can occur in paraUel with the SIP BYE request to UE 3 (step 4). 

Alternatively, the SCC AS can send the SIP BYE request to UE 2 prior to sending the SIP BYE request to 
UE3. 
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12-13. SIP 200 (OK) response (UE 2 to SCC AS via intermediate EM CN subsystem entities) 

UE 2 responds to the received SIP BYE request with a SIP 200 (OK) response. 

14-15. SIP 200 (OK) response (SCC AS to UE 1 via intermediate EM CN subsystem entities) 

Upon receiving SIP 200 (OK) responses from UE 2 and UE 3, the SCC AS responds to the SIP BYE request 
from UE 1 with a SIP 200 (OK) response. 

NOTE 2: The SIP 200 (OK) response in step 14 can be sent eariier by the SCC AS in response to the SIP BYE 

request received from UE l(step 3). For example, the SCC AS can send the SIP 200 (OK) response to UE 
1 after receiving the SIP 200 (OK) response from UE 3 (step 9). 



A. 14.3 Remote party UE releases collaborative session 

In this example, session release is initiated by the remote party UE (UE 3). UE 1 and UE 2 are included in a 
Collaborative Session with the remote party UE. The SCC AS ensures that all Controlee UEs involved in the 
Collaborative Session receive a request for session release in order to completely release the ongoing session. 
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Figure A.1 4.3-1 : Release of Collaborative Session initiated by remote party UE 

1. Collaborative Session currently exists in a dialog with UE 3 

A Collaborative Session involving UE 1 and UE 2 exists in a dialog with UE 3. Media paths exist between UE 1 
and UE 3 and between UE 2 and UE 3. In this scenario, UE 1 is the Controller UE in the Collaborative Session 
and thus maintains service control signalhng with the SCC AS. 
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2-4. SIP BYE request (UE 3 to SCC AS via intermediate EM CN subsystem entities) 

The remote party UE, UE 3, initiates session release by sending a SIP BYE request towards the Controller UE 
via the SCC AS serving the Controller UE. There is no Inter UE transfer specific content in the BYE request. 

5-6. SIP BYE request (SCC AS to UE 1 via intermediate IM CN subsystem entities) 

The SCC AS routes the SIP BYE request to UE 1, indicating to UE 1 that the remote party UE requests that the 

session is to be released. 

7-8. SIP BYE request (SCC AS to UE 2 via intermediate IM CN subsystem entities) 

The SCC AS, acting as a routing B2BUA sends a SIP BYE request to UE 2 to release the dialog it is involved in 
with UE 3 via the Collaborative Session. There is no Inter UE transfer specific content in the BYE request. 

NOTE 1: Step 7 can occur in parallel with step 5. Alternatively, step 7 can occur prior to step 5. The order in which 
the SCC AS sends the SIP BYE requests is not considered to be important. 

9-10. SEP 200 (OK) response (UE 1 to SCC AS via intermediate IM CN subsystems entities) 

UE 1 responds to the received SIP BYE request with a SIP 200 (OK) response. 
NOTE 2: Step 9 can occur immediately after UEl has received the SIP BYE request in step 6. 
11-12. SIP 200 (OK) response (UE 2 to SCC AS via intermediate EM CN subsystems entities) 

UE 2 responds to the received SIP BYE request with a SIP 200 (OK) response. 

13-15. SIP 200 (OK) response (SCC AS to UE 3 via intermediate EM CN subsystem entities) 

Upon receiving SIP 200 (OK) responses from UE 1 and UE 2, the SCC AS responds to the SIP BYE request 
from UE 3 with a SIP 200 (OK) response. 

NOTE 3: Step 13 can occur after the SCC AS has received the SIP BYE request step 4 since it is not necessary to 
wait for SIP BYE requests from UEl and UE2. 
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A.1 5 Signalling flows for media adding/deleting within 
collaborative session for inter-UE transfer 



A.1 5.1 Introduction 



A.I 5.2 Controller UE adds new media on controllee UE 



A.15.3 Controller UE releases media 



A.15.3.1 Controller UE releases media flow on controller UE 
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Figure A.15.3.1 : Controller UE releases media flow on controller UE 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalhng flow. 
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It is assumed that UE-1 is Controller UE having collaborative session control. A user has a multimedia session on his 
device UE-1 with voice (Media A) and UE-2 with video (Media B) media flows. Subsequently, the UE-1 (Controller 
UE) removes the media A flow that is active on Remote Party. 

1. SIP re-INVITE request (UE-1 to intermediate IM CN subsystem entities)- see example in table A.15.3.1-1 

UE-1 sends a SIP re-INVITE request towards Remote Party indicating Media A is to be removed in SDP offer. 

Table A.15.3.1-1 : SIP re-INVITE request (UE-1 to intermediate IM CN subsystem entities) 



INVITE <sip :userR_public@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 00a0c91e6bf 6 > SIP/2.0 
Via : SIP/2 . 0/UDP [3333: : eee : f f f : aaa : bbb] : 1357 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route : <sip : pcscf 1 . visitedl . net : 7531 ; Ir ; comp=sigcomp> , <sip : origOscscf 1 . homel . net ; lr> 

P-Asserted- Identity : "John Doe" <sip : userl_publicl@homel . net> 

P-Access-Network-Info : 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From : 

To : 

Call-ID: 

Cseq: 127 INVITE 
Require: sec -agree 
Proxy-Require: sec-agree 
Supported: lOOrel, precondition 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi- s=87654321 ; port- 
c=8642; port-s=7531 

Contact : <sip : userl_public@homel . net > ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 00a0c67t6br4 > 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Accept: application/sdp, application/3gpp- ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 3333 :: aaa : bbb : ccc : ddd 

s=- 

t = 

m=audio RTP/AVP 97 

c=IN IP6 3333 :: aaa: bbb: CCC: ddd 

a=rtpmap:97 PCMU/8000 

m=video RTP/AVP 98 

C=IN IP6 4444 :: aaa : bbb : ccc : ddd 

a=rtpmap:98 MPV/90000 



Editor" s Note: whether the controller UE needs to take all the SDP information for the media in other controllee UE 
in the SIP INVITE request is EES. 

2. SIP re-INVITE request 

Intermediate IM CN subsystem entities forward the SIP re-INVITE request to SCC AS according to standard IMS 
procedure. 

3. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) - see example in table A.15.3.1-3 

SCC AS sends a SIP re-INVITE request with all the media information at the remote party, set the post number for 
media A to 0, and forwards it towards Remote party through intermediate IM CN subsystem entities. 
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Table A.15.3.1-3: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE <sip : userRpublic2@homel . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6> IP/2 . 
Via: SIP/2. 0/UDP sccasl .homel .net;branch=z9hG4bK240f34 . 12 
Max-Forwards: 70 

Route : <sip : origOscscf 1 . homel . net ; lr> 

P-Asserted- Identity : "John Doe" <sip : userl_publicl@homel . net> 

P-Access -Network- Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From : 

To : 

Call-ID: 

Cseq: 127 INVITE 
Require: sec -agree 
Proxy-Require: sec-agree 
Supported: lOOrel, precondition 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321 ; port- 

c=8642; port-s=7531 
Contact : 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Accept: application/sdp, application/3gpp-ims+xml 
Content-Length: (...) 
v=0 

o=- 2987933615 2987933615 IN IP6 3333 : : aaa :bbb : ccc : ddd 

s = - 
t = 

m=audio RTP/AVP 97 

c = IN IP6 3333 : :aaa:bbb:ccc:ddd 

a=rtpmap:97 MPV/90000 

m=video 8888 RTP/AVP 98 

c=IN IP6 4444 :: aaa:bbb: ccc :ddd 

a=rtpmap:98 MPV/90000 



4. SIP re-EWITE request 

Intermediate IM CN subsystem entities forward the SIP re-INVITE request to Controller UE according to standard IMS 
procedure. 

5. SIP 200 (OK) response (Remote party to intermediate IM CN subsystem entities) - see example in 
table A.15.3.1-5 

Remote Party responses SIP 200 (OK) response with SDP answer. 

Table A.15.3.1-5: SIP 200 (OK) response (Remote party to IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 .net ;branch=dahtadf z4radgs . 12 , SIP/2. 0/UDP 
scscf 2 .homel .net ;branch=hsdf Idf 343 . 12 , SIP/2 . 0/UDP 
scscfl .homel .net ;branch=hsdfldf 563 22cc . 13 , SIP/2 . 0/UDP 
sccasl . homel . net ;branch=z9hG4bKnas34r2 .21 

From : 

To : 

Call-ID: 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 
Contact : 
Allow : 

Accept: application/sdp ; 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IP6 5555 :: aaa :bbb : ccc : ddd 
s=- 

c=IN IP6 5555: : aaa: bbb: CCC: ddd 

t = 

m=audio RTP/AVP 97 
a=rtpmap:97 MPV/90000 
m=video 6666 RTP/AVP 98 
a=rtpmap:98 MPV/90000 
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6. SIP 200 (OK) response 

7. SIP ACK request (SCC AS to intermediate IM CN subsystem entities) 

sec AS sends a SIP ACK request to remote party through the intermediate IM CN subsystem entities. 

8. SIP ACK request (intermediate EM CN subsystem entities to Remote party) 

9-10. SIP 200 (OK) response (SCC AS to UE-1 through intermediate IM CN subsystem entities) 

SCC AS responses SIP 200 (OK) response with SDP answer indicate that Media-A has been removed 
11-12. SIP ACK request (ControUer UE to SCC AS) 
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A. 15.3.2 Controller UE releases media flow on controllee UE 
A.1 5.3.2.1 Controller UE remove media at the controllee UE 



UE-1 



UE-2 



Intermediate 
IM CN entities 



sec AS 



■Collaborative session control ^ 

I 

Media-A between UE-1 and Remote Part^H 

I 



1. REFER 
- Refer-To: UE-2 
<remove Media-B> 




-Media-B between UE-2 and Remote Part^ 



2. REFER 
Refer-To: UE-2 » 

<remove Media-B> 



3. 202 Accepted — 
— 5. NOTIFY 



8. 200 OK— 
9. re-INVITE- 

12.200 OK— 

13. re-INVITE 
c=UE-1 
Media-A - 
c=UE-2 
Media-B=0 



14. re-INVITE 
c=UE-1 

— Media-A — 

c=UE-2 

Media-B=0 
I 

1 5. 200 (OK) 
_c=Remote Party_ 

Media-A 
Media-B=0 



16. 200 (OK) 
c=Remote Party, 
Media-A 
Media-B=0 

17. ACK 



-18. ACK- 



1 9.ACK- 



21.N0TIFY- 



24. 200 OK — I 

■Collabarative session control ^ 

I 

-Media-A between UE-1 and Remote Party^ 



Remote 
Party 



Figure A.15.3.2.1 :Controiier UE remove media at the controllee UE 



1-2. SIP REFER request (Controller UE to intermediate IM CN subsystem entities) - see example in 
table A. 15.3.2-1 

It is assumed that UE-1 is Controller UE having collaborative session control. A user has a multimedia session on his 
device UE-1 with a voice (Media A) and UE-2(Controllee UE) with a video (Media B) media flows and a voice (Media 
C). The controller UE wants to remove the video media (Media B) component on the controllee UE. 
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Table A.I 5.3.2.1-1 SIP REFER request (UE-1 to SCC-AS) 



REFER sip : scc-asohomel . net SIP/2.0 
Via : 

To: sip : scc-as@homel . net ; tag=24680 

From: sip : userl_pubicl@homel . net ; tag = 13579 

Call -ID: Cb03a0s09a2sdfglkj 490333 

CSeq: 93809824 REFER 

Max-Forwards: 70 

P- Preferred- Identity : 

Refer-To: sip : user2 public2(ahome2 . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a762 - OaOc91e6bf 6 
Require: target-dialog 

Target-dialog: cb03a0s09a2sdfglkj 13579 ; to-tag=abcdef ; f rom-tag=123456 

Contact : sip : userl_publicl@homel . net 

Allow: 

Accept : 

Content-Type : 

Content-Length : 



Editor" s Note: The content of the SIP REFER request needs FES. 
3-4. SIP 202 (Accepted) response 

SCC-AS sends SIP 202 ACCEPTED response to the controller UE-1 as response to the SIP REFER request. 

5-6. SIP NOTIFY request (SCC AS to UE-1 through mtermediate IM CN subsystem entities)-see example in 
table A.15.3.2-5 

SCC-AS sends SIP NOTIFY request to UE-1 to notify implicit subscription to the SIP REFER request results. 
Table A.I 5.3.2.1 -5 SIP NOTIFY request (SCC-AS to UE-1) 



NOTIFY 
Via : 

To: sip : userl pubicl@homel . net ; tag =24680 
From: sip : scc-as@homel . net ; tag=13579 
Call-ID^ 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact: sip: scc-as@homel.net 
Allow: 

Event : refer 

Subscript ion- St ate : active ; expires=3600 
Content-Type: message/sipf rag ; version=2 . 
Content-Length: (...) 

SIP/2.0 100 Trying 



7-8. SIP 200 OK response (UE-1 to SCC-AS through intermediate IM CN subsystem entities) 

The controller UE, UE-1, acknowledges the SIP NOTIFY request by sending SIP 200 OK response to SCC-AS. 

9-10. SIP re-INVITE request (SCC AS to UE-2 through intermediate IM CN subsystem entities) 

SCC AS sends a SIP re-INVITE request towards Controllee UE (UE-2). 

11-12. SIP 200 (OK) response (UE-2 to SCC AS through intermediate IM CN subsystem entities) 

13. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) - see example in table A.15.3.2-13 

SCC AS sends a SIP re-INVITE request with all the media information at the remote party, set the port number for 
media B to 0, and forwards it to remote party through intermediate IM CN subsystem entities. 
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Table A.1 5.3.2.1 -13: SIP re-INVITE request (SCO AS to intermediate IM CN subsystem entities) 



INVITE <sip : userR_publicl@homel . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a762-00a0c91e6bf 6> SIP/2 . 
Via: SIP/2. 0/UDP sccasl .homel .net;branch=z9hG4bKjias34r2 . 12 
Max-Forwards: 70 

Route : <sip : origOscscf 1 . homel . net ; lr> 

P-Asserted- Identity : "John Doe" <sip : userl_publicl@homel . net> 

P-Access -Network- Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From : 

To : 

Call-ID: 

Cseq: 127 INVITE 
Require: sec -agree 
Proxy-Require: sec-agree 
Supported: lOOrel, precondition 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321 ; port- 

c=8642; port-s=7531 

Contact: <sip: userl_public@homel . net> ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 00a0c67t6br4> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Accept: application/sdp, application/3gpp-ims+xml 
Content-Length: 

v=0 

o=- 2987933615 2987933615 IN IP6 3333 : : aaa :bbb : ccc : ddd 

s=- 

c=IN IP6 3333 : :aaa:bbb:ccc:ddd 

t = 

m=audio 6666 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=audio 4567 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video RTP/AVP 98 
a=rtpmap:98 MPV/90000 



14. SIP re-INVITE request (intermediate IM CN subsystem entities to Remote Party) 

15. SIP 200 (OK) response (Remote party to intermediate IM CN subsystem entities) - see example in 
table A.15.3.2-15 

Remote party send a SIP 200 (OK) response with SDP answer. 

Table A.1 5.3.2.1 -15 SIP 200 (OK) (Remote Party to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 .net ;branch=343asdf aredf atz . 12 , SIP/2. 0/UDP 

scscf 2 .homel .net ;branch=fsc35avhthaz4 . 22 , SIP/2 . 0/UDP 

scscfl .homel .net ;branch=fsc35avhthaz4 . 12 , SIP/2 . 0/UDP 

sccasl .homel .net;branch=z9hG4bKnas34r2 . 14 
From: 
To: 

Call-ID: 

Cseq: 12 7 INVITE 

Supported: lOOrel; precondition 

Contact : 

Allow: 

Accept: application/sdp; 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IP6 5555 :: aaa :bbb :: ccc : ddd 
s=- 

c=IN IP6 5555: : aaa: bbb: : ccc: ddd 
t=0 

m=audio 4444 RTP/AVP 97 
a=rtpmap:9777 PCMU/8000 
m=audio 4545 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video RTP/AVP 98 
a=rtpmap:98 MPV/90000 



16. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 
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17-18. SIP ACK request (SCC AS to remote party) 
19-20. SIP ACK request (from SCC-AS to UE-2) 

21-22. SIP NOTIFY request (SCC-AS to UE-l)-see example table A.15.3.2-21 

SCC-AS sends SIP NOTIFY request to controller UE, UE-1 to inform about the success status of the inter-UE transfer. 



Table A.I 5.3-2.1 -21 SIP NOTIFY request (SCC-AS to UE-1) 



NOTIFY 




Via: 




To: sip:userl pubicl@homel.net 


tag = 13579 


From: sip : scc-as@homel . net ; tag 


= 24680 


Call-ID: 




CSeq: 




Max- Forwards : 




P- Asserted- Identity : 




Require : 




Contact: sip: scc-as@homel.net 




Allow: 




Event : refer 




Subscription-State : terminated; 


reason=noresource 


Content-Type: message/sipf rag 


version=2 . 


Content-Length: (...) 




SIP/2.0 200 OK 





Editor" s Note: Whether the SDP information is needed in the SIP NOTIFY request is EES. 
23-24. SIP 200 OK response (UE-1 to SCC-AS) 

The controller UE,UE-1 acknowledges the SIP NOTIFY request by sending a SIP 200 OK response to SCC-AS. 
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A. 15.3.2.2 Controller UE remove the controllee UE form the collaborative session 



UE-1 



UE-2 



Intermediate 
IM CN entities 



sec AS 



•Collabarative session control- 



-Media-A between UE-1 and Remote Party- 



I 



1. REFER 
- Refer-To: UE-2 - 
<remove Media-B> 



-Media-B between UE-2 and Remote Party- 



2. REFER 
- Refer-To: UE-2 » 
<remove Media-B> 



-4. 202 Accepted- 
I 



-6.N0TIFY- 
I 




20.ACK- 



-22.NOTIFY- 
-23. 200 OK- 



1-3. 202 Accepted — 
I 5. NOTIFY 



-8. 200 OK- 
-9. BYE — 



-12.200 OK— 

13. re-INVITE 

c=UE-1 
- Media-A - 
c=UE-2 
Media-B=0 



14. re-INVITE 
c=UE-1 

— Media-A — 

c=UE-2 

Media-B=0 
I 

1 5. 200 (OK) 
_c=Remote Party_ 

Media-A 
Media-B=0 



16. 200 (OK) 
_c=Remote Party, 
Media-A 
Media-B=0 

17. ACK 



-18. ACK- 



-19.ACK- 



-21.N0TIFY- 



-24. 200 OK- 



■Collabarative session control ^ 

I 

Media-A between UE-1 and Remote Party- 



Remote 
Party 



-► 



Figure A.15.3.2.2:Controller UE remove the controllee UE from the collaborative session 

1-2. SIP REFER request (Controller UE to intermediate IM CN subsystem entities) - see example in 
table A.15.3.2.2-1 

It is assumed that UE-1 is Controller UE having collaborative session control. A user has a multimedia session on his 
device UE-1 with a voice (Media A) and UE-2(Controllee UE) with a video (Media B) media flow. The controller UE 
wants to remove the controllee UE from the collaborative session. 
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Table A.I 5.3.2.2-1 SIP REFER request (UE-1 to SCC-AS) 



REFER sip : scc-asohomel . net SIP/2.0 






Via : 






To: sip : scc-as@homel . net ; tag=24680 






From: sip:userl pubiclohomel . net ; tag = 


13579 




Call -ID: Cb03a0s09a2sdfglkj 490333 






CSeq: 93809824 REFER 






Max-Forwards: 70 






P- Preferred- Identity : 






Refer-To: <sip:user2 public20home2.net 


gr=urn : uuid : f 81d4f ae- 


7dec-lldO-a762- 


00a0c91e6bf 6 ; method=BYE> 






Require: target-dialog 






Target -dialog: cb0 3a0s0 9a2sdf glkj 13 579 


to-tag=abcdef ; from- 


tag=123456 


Contact: sip:userl publicl@homel.net 






Allow : 






Accept : 






Content-Type : 






Content-Length : 







Editor's Note: The content of the REFER request needs FFS. 
3-4. SIP 202 (Accepted) response 

SCC-AS sends SIP 202 ACCEPTED response to controller UE-1 as response to SIP REFER request. 

5-6. SIP NOTIFY request (SCC AS to UE-1 through intermediate IM CN subsystem entities)-see example in 
table A.15.3.2.2-5 

SCC-AS sends SIP NOTIFY request to UE-1 to notify implicit subscription to the REFER request results. 

Table A.15.3.2.2-5 SIP NOTIFY request (SCC-AS to UE-1) 



NOTIFY 
Via : 

To: sip : user 1 pubic lohomel . net ; tag =24680 
From: sip : scc-asOhomel . net ; tag=13579 
Call-ID^ 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact: sip: scc-as®homel . net 
Allow: 

Event : refer 

Subscript ion- St ate : active ; expires = 360 
Content-Type: message/sipf rag ; version=2 . 
Content-Length: (...) 

SIP/2.0 100 Trying 



7-8. SIP 200 OK response (UE-1 to SCC-AS through intermediate IM CN subsystem entities) 

The controller UE, UE-1, acknowledges the SIP NOTIFY request by sending SIP 200 OK to SCC-AS. 

9-10. SIP BYE request (SCC AS to UE-2 through intermediate IM CN subsystem entities) 

SCC AS sends a SIP BYE request towards ControUee UE (UE-2). 

11-12. SIP 200 (OK) response (UE-2 to SCC AS through intermediate IM CN subsystem entities) 

13. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) - see example in table A.15.3.2.2- 
13 

SCC AS sends a SIP re-INVITE request with all the media information at the remote party, set the port number for 
media B to 0, and forwards it to remote party through intermediate IM CN subsystem entities. 
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Table A.1 5.3.2.2-1 3: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE <sip : userR_publicl@homel . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a762-00a0c91e6bf 6> SIP/2 . 
Via: SIP/2. 0/UDP sccasl .homel .net;branch=z9hG4bKjias34r2 . 12 
Max-Forwards: 70 

Route : <sip : origOscscf 1 . homel . net ; lr> 

P-Asserted- Identity : "John Doe" <sip : userl_publicl@homel . net> 

P-Access -Network- Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From : 

To : 

Call-ID: 

Cseq: 127 INVITE 
Require: sec -agree 
Proxy-Require: sec-agree 
Supported: lOOrel, precondition 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321 ; port- 

c=8642; port-s=7531 

Contact: <sip: userl_public@homel . net> ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 00a0c67t6br4> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Accept: application/sdp, application/3gpp-ims+xml 
Content-Length: 

v=0 

o=- 2987933615 2987933615 IN IP6 3333 : : aaa :bbb : ccc : ddd 

s=- 

c=IN IP6 3333 : :aaa:bbb:ccc:ddd 

t = 

m=audio 6666 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video RTP/AVP 98 
a=rtpmap:98 MPV/90000 



14. SIP re-INVITE request (intermediate IM CN subsystem entities to Remote Party) 

15. SIP 200 (OK) response (Remote party to intermediate IM CN subsystem entities) - see example in 
table A.15.3.2.2-15 

Remote party send a SIP 200 (OK) response with SDP answer. 

Table A.15.3.2.2-15 SIP 200 (OK) response (Remote Party to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 .net ;branch=343asdf aredf atz . 12 , SIP/2. 0/UDP 

scscf2 .homel. net ;branch=fsc35avhthaz4 .22, SIP/2 . 0/tJDP 

scscfl .homel .net ;branch=fsc35avhthaz4 . 12 , SIP/2 . 0/tJDP 

sccasl .homel .net;branch=z9hG4bKnas34r2 . 14 
From: 
To: 

Call-ID: 

Cseq: 12 7 INVITE 

Supported: lOOrel; precondition 

Contact : 

Allow: 

Accept: application/sdp; 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IP6 5555 :: aaa :bbb :: ccc : ddd 
s=- 

c=IN IP6 5555: : aaa: bbb: : ccc: ddd 
t=0 

m=audio 4444 RTP/AVP 97 
a=rtpmap:9777 PCMU/8000 
m=video RTP/AVP 98 
a=rtpmap:98 MPV/90000 



16. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 
17-18. SIP ACK request (SCC AS to remote party) 
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19-20. SIP ACK request (from SCC-AS to UE-2) 

21-22. SIP NOTIFY request (SCC-AS to UE-l)-see example in table A.15.3.2.2-21 

SCC-AS sends SIP NOTIFY request to controller UE, UE-1 to inform about the success status of the inter-UE transfer. 



Table A.15.3.2.2-21 SIP NOTIFY request (SCC-AS to UE-1) 



NOTIFY 




Via : 




To: sipiuserl pubicl@homel.net 


tag = 13579 


From: sip : scc-as@homel . net ; tag 


= 24680 


Call-ID: 




CSeq: 




Max- Forwards : 




P- Asserted- Identity : 




Require : 




Contact: sip: scc-as@homel.net 




Allow: 




Event : refer 




Subscription-State : terminated; 


reason=noresource 


Content-Type: message/sipf rag 


version=2 . 


Content-Length: (...) 




SIP/2.0 200 OK 





Editor's Note: Whether the SDP information is needed in the SIP NOTIFY request is FES. 
23-24. SIP 200 OK response (UE-1 to SCC-AS) 

The conti-oller UE,UE-1 acknowledges the SIP NOTIFY request by sending a SIP 200 OK response to SCC-AS. 
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A. 15.4 Controllee UE releases media 



UE-1 




UE-2 






Intermediate 
IM CN entities 



sec 

AS 



-Collabarative session control 1 

Media-A between UE-1 and Remote Party- 



Media-B between UE-2 and Remote Party- 



1. re-INVITE- 



-14. 200 (OK)- 
— 15. ACK — 



-2. re-INVITEH 
-3, re-INVITE — I 



-6, 200 (OK)- 
— 7, ACK — 



9. re-INVITE 

c=UE-1 
- Medla-A - 
c=UE-2 
Medla-B=0 



10. re-INVITE 
c=UE-1 
— Medla-A — 
c=UE-2 
Medla-B=0 
11.200 (OK) 
_c=Remote Party_ 
Medla-A 
Medla-B=0 



12. 200 (OK) 
_c= Remote Party 
Media-A 
Medla-B=0 

hi 3. 200 (OK)— 



-16. ACK- 
-17. ACK- 



-18. ACK- 



Collabarative session control- 



I 



-Media-A between UE-1 and Remote Party- 



Remote 
Party 



Figure A.15.4: Controllee UE releases media 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

It is assumed that UE-I is Controller UE having collaborative session control, a user has a multimedia session on his 
device UE-I with voice (Media A) and UE-2(Controllee UE) video (Media B) media flows. Subsequently, the UE-2 
(Controllee UE) removes the media B flow that is active on Remote Party. 

1-2. SIP re-EWITE request (UE-2 to SCO AS through IM CN subsystem entities) 

A UE-2 wants to release media B active on remote party. For this purpose the UE-2 sends a SIP re-INVITE request to 
the sec AS through the IM CN subsystem entities. 

3. SIP re-INVITE request (from SCC-AS to intermediate IM CN subsystem entities) - see example in table A.15.4- 
3 

SCC-AS sends SIP re-INVITE request to controller UE, UE-1 to inform that the controUee UE wants to release one 
media, and SCC AS would like to add this media back to the controller UE. 



ETSI 



3GPP TS 24.237 version 9.1 .0 Release 9 1 33 ETSI TS 1 24 237 V9.1 .0 (201 0-01 ) 

Table A.1 5.4-3: SIP re-INVITE request (SCC AS to controller UE) 



INVITE <sip : userl_publicl@homel . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a762-00a0c91e6bf 6> SIP/2 . 
Via: SIP/2. 0/UDP sccasl .homel .net;branch=z9hG4bKjias34r2 . 12 
Max-Forwards: 70 

Route : <sip : origOscscf 1 . homel . net ; lr> 

P-Asserted-Identity: "John Doe" <sip:user3_public3@home3 .net> 
Privacy: none 
From : 
To : 

Call-ID: 

Cseq: 127 INVITE 
Require : 

Contact: <sip: user3_public3@home3 . net > ; gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c67t6br4> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Content-type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 3333 : : aaa :bbb : ccc : ddd 

s=- 

t=0 

m=audio 5555 RTP/AVP 97 

c = IN IP6 3333 : :aaa:bbb:ccc:ddd 

a=rtpmap:97 PCMU/90000 

m=video 3 000 RTP/AVP 98 

c=IN IP6 4444 :: aaa : bbb: ccc : ddd 

a=rtpmap:98 MPV/90000 



4. SIP re-EWITE request (intermediate IM CN subsystem entities to controller UE, UE-1) 

5. SIP 200 (OK) response (controller UE, UE-1 to intermediate IM CN subsystem entities) - see example in 
table A.15.4-5 

In this case, the controller UE does not want to add this media on itself, but like to delete this media within the 
collaborative session. The controller UE cknowledges the SIP re-INVITE request by sending SIP 200 (OK) response to 
SCC-AS with the port number set to zero for this media. 

Table A.15.4-5: SIP 200 (OK) (controller UE to SCC AS) 



SIP/2.0 200 OK 
Via : 
From : 
To : 

Call-ID: 
Cseq : 

Contact: <sip: userl_publicl@homel .net>; gr=urn:uuid: f 81d4fae-7dec-lld0-a765-00a0c43t6br4> 

Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IP6 5555 :: aaa : bbb :: ccc : ddd 

s = - 

c=IN IP6 5555: : aaa: bbb: : ccc: ddd 

t = 

m=audio 4444 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video RTP/AVP 98 
a=rtpmap:98 MPV/9000 



6. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 
7-8.SIP ACK (SCC AS to controller UE) 

9. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities)-see example in table A.15.4-9 

SCC AS sends a SIP re-INVITE request to update the remote leg that the meida B shall be released.. 
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Table A.1 5.4-9: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE <sip : user3public3@home3 . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a762-00a0c91e6bf 6> SIP/2 . 
Via: SIP/2. 0/UDP sccasl .homel .net;branch=z9hG4bKjias34r2 . 12 
Max- Forwards : 

Route : <sip : origOscscf 1 . homel . net ; lr> 

P-Asserted-Identity: "Jake" <sip:userl_publicl@homel .net> 

Privacy: none 

From : <sip : userl_publicl@homel . net > ; tag=17182 8 
To: <sip : user3_pubic3®home3 . net> ; tag = 66666 
Call -ID: Cb0 3a0s09a2sdfglkj4 90333 
Cseq: 127 INVITE 

Supported: lOOrel, precondition 

Contact: <sip: userlpubliclohomel . net > ; gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c43t6br4> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Accept: application/sdp 
ontent-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 3333 : : aaa :bbb : ccc : ddd 

s=- 
t=0 

m=audio 5555 RTP/AVP 97 

c = IN IP6 3333 : :aaa:bbb:ccc:ddd 

a=rtpmap:97 PCMU/90000 

m=video RTP/AVP 98 

C=IN IP6 4444 : :aaa:bbb:CCC:ddd 

a=rtpmap:98 MPV/90000 



10. SIP re-INVITE request (intermediate IM CN subsystem entities to remote party) 

11. SIP 200 (OK) response (Remote Party to intermediate EM CN subsystem entities) - see example in 
table A.15.4-11 

Remote Party response SIP 200 (OK) with SDP offer containing Media A and Media B information. 

Table A.15.4-11 : SIP 200 (OK) (Remote Party to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: 

To: 

Call-ID: 

Cseq: 12 7 INVITE 

Supported: lOOrel; precondition 

Contact: <sip: user3 j>ublic3@home3 .net>; gr=urn:uuid: f 81d4fae-7dec-lld0-a765-00a0c67t6br4> 
Allow: 

Accept: application/sdp; 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IP6 5555 :: aaa :bbb :: ccc : ddd 
s=- 

c=IN IP6 5555: : aaa: bbb: : ccc: ddd 
t=0 

m=audio 4444 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video RTP/AVP 98 
a=rtpmap:98 MPV/9000 



12. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 
13-14. SIP 200 (OK) response (SCC AS to UE-2 through IM CN subsystem entities) 

SCC AS response 200 (OK). 

15-16. SIP ACK (controUee UE to SCC AS) 

17-18. SIP ACK (SCC AS to Remote Party) 
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A.15.5 Controllee UE modifies media on itself 
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Figure A.15.5: Controiiee UE modifies media on itself 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalhng flow. 

It is assumed that UE-1 is Controller UE having collaborative session control. A user has a multimedia session on his 
device UE-1 with voice (Media A) and UE-2 with video (Media B) media flows. Subsequently, the UE-2 (Controllee 
UE) modifies the media B flow that is active on Remote Party. 

l.SIP re-INVITE request (UE-2 to intermediate IM CN subsystem entities)- see example in table A.15.5-1 

UE-2 sends a SIP re-INVITE request towards Remote Party containing Media B using SDP offer. 
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Table A.1 5.5-1 : SIP re-INVITE request (UE-2 to intermediate IM CN subsystem entities) 



INVITE <sip:userR_publicl@homel.net;gr=urn:uuid: f 81d4f ae- 7dec- lldO -a765 - OaOc91e6bf 6> SIP/2 .0 
Via : SIP/2 . 0/UDP [4444: : aaa : bbb : ccc : ddd] : 1357;comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route : <sip : pcscf 1 . visitedl . net : 7531 ; Ir ; comp=sigcomp> , <sip : origOscscf 1 . homel . net ; lr> 
P-Asserted- Identity : "John Doe2" <sip : userl_public2@homel . net> 
P-Access -Network- Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
Privacy: none 
From : 

To: Call-ID: 
Cseq: 127 INVITE 
Require: sec-agree 
Proxy-Require: sec-agree 
Supported: lOOrel, precondition 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi- s=87654321 ; port- 
c=8642; port-s=7531 

Contact: <sip: userl_public®homel . net> ; gr=urn:uuid: f 81d4f ae-7dec-lld0-a765- 

00a0c67t6br4>Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, 

NOTIFY 

Accept: application/sdp , application/3gpp-ims+xml 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 4444 :: aaa : bbb : CCC : ddd 
S=- 

c=IN IP6 4444 :: aaa : bbb : CCC : ddd 

t = 

m=video 4444 RTP/AVP 98 
a=rtpmap:98 MPV/90000 



2. SIP re-INVITE request (intermediate EM CN subsystem entities to SCC AS) 

Intermediate IM CN subsystem entities forward the SIP re-INVITE request to SCC AS according to standard IMS 
procedure. 

3. SIP re-EWITE request (SCC AS to intermediate IM CN subsystem entities) - see example in table A.15.5-3 

SCC AS sends a SIP re-INVITE request to Remote party through the intermediate IM CN subsystem entities containing 
Media A and Media B information in SDP offer. 
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Table A.1 5.5-3: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE <sip : userRpubliclOhomel . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6> SIP/2 . 
Via: SIP/2. 0/UDP sccasl.homel.net;branch=z9hG4bK240a48.12 
Max-Forwards: 70 
Route : 

P- Asserted- Identity: 
P- Access -Network- Info : 
Privacy: 
From : 
To : 

Call-ID: 
Cseq : 
Require : 
Proxy-Require : 
Supported : 
Security-Verif y : 
Contact : 
Allow : 
Accept : 
Content-Type : 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 3333 : : aaa :bbb : ccc : ddd 

s=- 

t = 

m=audio 2222 RTP/AVP 97 

c = IN IP6 3333 : :aaa:bbb:ccc:ddda=rtpmap:97 MPV/90000 

m=video 4444 RTP/AVP 98 

c=IN IP6 4444 :: aaa ibbb: ccc : ddd 

a=rtpmap:98 MPV/90000 



4. SIP re-INVITE request (intermedia IM CN subsystem entities to Remote party) 

5. SIP 200 (OK) response (Remote Party to intermediate IM CN subsystem entities) - see example in 
table A.15.5-5 

Remote Party response SIP 200 (OK) response with SDP answer. 

Table A.15.5-5: SIP 200 (OK) response (Remote Party to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 .net ;branch=z9hG4bK240f 26 . 3 , SIP/2. 0/UDP 
scscf 2 .homel.net ;branch=z9hG4bK332d25 .1, SIP/2 . 0/UDP 
scscf 1 .homel .net;branch=z9hG4bK332d25 .2, SIP/2 . 0/UDP 
sccasl .homel .net;branch=z9hG4bK240a48 . 12 

From: 

To: 

Call-ID: 

Cseq: 12 7 INVITE 

Supported: lOOrel; precondition 

Contact : 

Allow: 

Accept: application/sdp; 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IP6 5555 :: aaa :bbb : ccc : ddd 
s=- 

c=IN IP6 5555: : aaa: bbb: ccc: ddd 
t=0 

m=audio 4444 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video 6666 RTP/AVP 98 
a=rtpmap:98 MPV/90000 



6. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

7-8. SIP ACK request (SCC AS to Remote party through intermediate IM CN subsystem entities) 
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sec AS sends an SIP ACK request to Remote Party through intermediate IM CN subsystem entities. 

9. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) - see example in table A.15.5-9 

sec AS response SIP 200 (OK) response containing Media B information and send it to UE-2 through intermediate IM 
CN subsystem entities 

Table A.15.5-9 SIP 200 OK response (SCC AS to intermediate IM CN subsystem entities) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP sccasl . homel . net ;branch=z9hG4bK240f 42 . 22 , 
From : 
To : 

Call-ID: 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 
Contact : 
Allow : 

Accept: application/sdp ; 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IP6 5555 : : aaa : bbb : ccc : ddd 
s = - 

c=IN IP6 5555 :: aaa : bbb : ccc : ddd 
t = 

m=video 6666 RTP/AVP 98 
a=rtpmap:98 MPV/90000 



10. SIP 200 (OK) response (intermediate IM CN subsystem entities to UE-2) 

11-12. SIP ACK request (UE-2 to SCC AS through intermediate IM CN subsystem entities) 

UE-2 sends an SIP ACK request to intermediate IM CN subsystem entities which is terminated by SCC AS. 

Editor's Note: Whether a NOTIFY is needed to send to the controller UE to inform that the characteristics of meida 
B in controllee UE has modifed is EES. 

A. 15.6 Remote party adds new media on controllee UE 

It is assumed that UE-1 is controller UE having collaborative session control. A user has a multimedia session on his 
device UE-1 with voice (Media A) and video (Media B) media flows. Subsequently, the Remote Party adds the media B 
flow. In this scenario it is assumed that controller UE, UE-1 automatically initiates the addition of the new media on 
UE-2 (Controllee) without first alerting the user and sends a SIP REFER request prior to sending back a SIP 200 (OK) 
response to the SIP re-INVITE request. 
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Figure A.15.6: Remote party add new media on Controllee UE 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalUng flow. 

1. SIP re-EWITE request (Remote Party to intermediate IM CN subsystem entities) - see example in table 
A.15.6-1 
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Remote Party sends a SIP re-INVITE request towards Controller UE (UE-1) indicating Media B is to be added in SDP 
offer. 

Table A.1 5.6-1 : SIP re-INVITE request (Remote Party to intermediate IM CN subsystem entities) 



INVITE <sip :userl_publicl®homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6> SIP/2.0 
Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route : <sip : pcscf 2 . visited2 . net : 7531 ; Ir ; comp=sigcomp> , <sip : origOscscf 2 . homel . net ; lr> 
P-Asserted- Identity : "David Fan" <sip : user3_public3@home3 . net> 
P-Access-Network-Info : 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
Privacy: none 
From : 
To : 

Call-ID: 

Cseq: 127 INVITE 
Require: sec-agree 
Proxy-Require: sec-agree 
Supported: lOOrel, precondition 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi- s=87654321 ; port- 
c=8642; port-s=7531 

Contact : <sip : user3_public3®home3 . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c67t6br4> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Accept: application/sdp , application/3gpp-ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 
s = - 

c=IN IP6 5555 :: aaa :bbb : ccc :ddd 

t = 

m=audio 6666 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video 4444 RTP/AVP 98 
a=rtpmap:98 MPV/90000 



2-4. SIP re-INVITE request 

Intermediate IM CN subsystem entities forward the SIP re-INVITE request to UE-1 via SCC AS according to standard 
IMS procedure. 

5-6. SIP REFER request (UE-1 to SCC AS through intermediate IM CN subsystem entities) - see example in 
table A.15.6-5 

The controller UE determines to add the new media (Media B) on the controllee UE. The controller UE, UE-1 sends a 
SIP REFER request to the SCC AS containing a Refer-To header field containing the GRUU of controllee UE, UE-2 
and a body parameter containing an m line for audio set to and an m line for video with the port number set to the port 
number of the video media line from the SDP offer in the SIP re-INVITE request from the remote UE. The SIP REFER 
request also includes a Target-dialog header field containing the details of the dialog for the existing session between 
controller UE, UE-1 and the remote UE. 

Table A.15.6-5 SIP REFER request (UE-1 to SCC-AS) 



REFER sip : scc-as®homel . net SIP/2.0 
Via : 

To: sip : user3_public3@home3 . net 

From : sip : userl_pubicl@homel . net ; tag=34 719 

Call-ID: Cb03a0s0 9a2sdfglkj4 90333 

CSeq: 93809824 REFER 

Max-Forwards: 70 

P- Preferred- Identity : 

Refer-To: < sip : userl public2@home2 . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a76 5- 
00a0c91e6bf 6 ?body=m%3Daudio%200%20RTP%2FAVP%2097%0Dm%3Dvideo%204444%20RTP%2FAVP%209B> 
Require: target-dialog 

Target -dialog: cb03a0s09a2sdfglkj 490333 ; remote- tag=13579 ; local- tag=24680 

Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765- 00a0c91e6bf 6 > 

Allow: 

Accept :message/sipf rag 
Content-Length : 
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7-8. SIP 202 (Accepted) response 

SCC-AS sends a SIP 202 ACCEPTED response to controller UE-1 as response to the SIP REFER request. 

9-10. SIP NOTIFY request (SCC AS to UE-1 through mtermediate IM CN subsystem entities)-see example in 
table A.15.3.2-5 

SCC-AS sends a SIP NOTIFY request to UE-1 to notify implicit subscription to the SIP REFER request results. 

Table A.15.3.2-5 SIP NOTIFY request (SCC-AS to UE-1) 



NOTIFY sip :userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2.0 
Via : 

To: sip : userl pubiciohomel . net ; tag =67912 
From : sip : user3_public3@home3 . net ; tag=34 719 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact : <sip : user3_public3@home3 . net ;gr=urn :uuid : f 81d4f ae-7dec-lld0-a7S5-00a0c67tSbr4> 
Allow: 

Event : refer 

Subscript ion- St ate : active ; expires=3600 
Content-Type : message/sipf rag; version=2 . 
Content-Length: (...) 

SIP/2.0 100 Trying 



11-12. SIP 200 (OK) response (UE-1 to SCC-AS through intermediate IM CN subsystem entities) 

The controller UE, UE-1, acknowledges the SIP NOTIFY request by sending a SIP 200 OK response to SCC-AS. 

13-14. SIP 200 (OK) response (UE-1 to SCC-AS through intermediate IM CN subsystem entities)-see example in 
table A.15.6-13 

The controller UE responds to the SIP re-INVITE request in step 4. 

Table A.15.6-13: SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 3 , SIP/2. 0/UDP 
scscf 1 .homel .net ;branch=z9hG4bK3 3 2b2 3 . 1 , SIP/2 . 0/UDP 
sccasl . homel . net ; branch=z9hG4bKnas34r4 . 12 

From : 

To : 

Call-ID: 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 
Contact : 
Allow : 

Accept: application/sdp; 
Content-Type : application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933300 2987933300 IN IPS 3333 : : aaa : bbb : ccc : ddd 
s=- 

c=IN IP6 3333 :: ccc : ddd: aaa : bbb 

t = 

m=audio 8888 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video RTP/AVP 98 



15-16. SIP ACK (SCC AS to UE-1 through intermediate IM CN subsystem entities) 

17. SIP INVITE request (SCC AS to intermediate IM CN subsystem entities)-see example in table A.15.6-15 

Editor's Note: This message can be sent as soon as the SIP REFER request is received. 
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sec AS sends a SIP INVITE request towards UE-2 through intermediate IM CN subsystem entities indicating Media B 
information in SDP offer. 

Table A.15.6-17: SIP INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE sip : user l_public2@homel . net ; gr=urn :uuid: 2ad892 0e-4 8a5-4a74 -8d99-ad76cc7f c74 SIP/2 . 
Via: SIP/2. 0/UDP sccasl . homel . net ;branch=z9hG4bKnas34r2 . 12 
Max - Forwards : 7 

Route : <sip : term@scscf 1 .homel .net ; lr>, <sip:pcscf 1 . visitedl .net : 7538 ; Ir ; comp=sigcomp> 
P-Asserted-Identity: "John Doe" <sip:user3_public3@home3 .net> 

Privacy: none 

From : <sip : user3_public3@home3 . net > ; tag=17182 8 
To : <sip : userl_public2@homel . net> 
Call -ID: Cb0 3a0s0 9a2sdfglkj4 90333 
Cseq: 127 INVITE 

Supported: lOOrel, precondition 

Ref erred-By : sip : userl_pubicl@homel . net 

Contact : <sip : user3_public3@home3 . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a76 5 - 0a0c6 7t6br4> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Accept: application/sdp 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 
s = - 

c = IN IP6 4444 : :bbb : aaa : ccc : ddd 

t = 

m=audio RTP/AVP 97 
m=video 4444 RTP/AVP 98 
a=rtpmap:98 MPV/90000 



18, SIP INVITE request (intermediate IM CN subsystem entities to UE-2) 

19. SIP 200 (OK) response (UE-2 to intermediate IM CN subsystem entities) - see example in table A.15.6-19 

UE-2 responds with a SIP 200 (OK) response containing the SDP answer. 

Table A.15.6-19: SIP 200 (OK) response (UE-2 to intermediate IIUI CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscfl. visitedl. net;branch=z9hG4bK240f34. 3, SIP/2 . 0/UDP 

scscfl .homel .net ;branch=z9hG4bK332b23 . 1 , SIP/2 . 0/UDP 

sccasl .homel .net ;branch=z9hG4bKnas34r2 . 12 
From : 

To : <sip : userl_public2@homel . net> ; tag=237674 
Call-ID: 

Cseq: 127 INVITE 

Supported: 10 Orel; precondition 

Contact : <sip :userl_public2@homel . net ; gr=urn :uuid: 2ad892 0e-4 8a5-4a74 - 8d99- 
ad76cc7f c74> ; +g . 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel " 

Allow : 

Accept: application/sdp; 
Content-Type : application/sdp 
Content -Length: (...) 

v=0 

0=- 2987933300 2987933300 IN IP6 4444 :: aaa :bbb : ccc : ddd 
s=- 

c=IN IP6 4444 :: aaa : bbb: ccc : ddd 

t = 

m=audio RTP/AVP 97 
m=video 6666 RTP/AVP 98 
a=rtpmap:98 MPV/90000 



20. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 
21-22. SIP ACK (SCC AS to UE-2 through intermediate IM CN subsystem entities) 

23. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) - see example in table A.15.6-23 
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In response to the SIP re-INVITE from Remote Party,SCC AS sends a SIP 200 (OK) containing the SDP answer 
towards Remote Party through IM CN subsystem entities, which includes Media A and Media B information. 

Table A.15.6-23: SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG6bKnas34r4 , SIP/2. 0/UDP 
scscf 2 . visited2 . net ; branch=34qtrada3333 . 22 , SIP/2 . 0/UDP 
pcscf 2 .visited2 . net ; branch=34qtrada5454 . 12 , SIP/2 . 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 

From : 

To : 

Call-ID: 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 

Contact : 

Allow: 

Accept: application/sdp; 
Content-Type : application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IP6 3333 :: aaa : bbb : ccc : ddd 
s = - 
t = 

m=audio 8888 RTP/AVP 97 

c=IN IPS 3333 :: ccc :ddd: aaa :bbb 

a=rtpmap:97 PCMU/8000 

m=video 6666 RTP/AVP 98 

c=IN IP6 4444 :: bbb : aaa : ccc : ddd 

a=rtpmap:98 MPV/90000 



24. SIP 200 (OK) response (intermediate IM CN subsystem entities to Remote Party) 
25-26. SIP ACK (Remote Party to SCC AS through intermediate IM CN subsystem entities) 

Remote Party sends a SIP ACK request to intermediate IM CN subsystem entities which terminated by SCC AS. 
27-28. SIP NOTIFY request (from SCC AS to controller UE, UE-1) 

SCC- AS sends a SIP NOTIFY request to controller UE, UE-1 to inform about the success status if the inter-UE transfer. 

Table A.I 5.6-27 SIP NOTIFY request (SCC AS to UE-1) 



NOTIFY sip :userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2.0 
Via : 

To: sip : userl publiciohomel . net ; tag=67912 
From; sip : user 3 public3®home3 . net ; tag=34 719 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact : <sip : user3_public3@home3 . net ;gr=urn :uuid : f 81d4f ae-7dec-lld0-a765-00a0c67t6br4> 
Allow: 

Event : refer 

Subscription-State : terminated; reason=noresource 
Content-Type : message/sipf rag; version=2 . 
Content-Length: (...) 

SIP/2.0 200 OK 

Content-Type: application/sdp 
m=audio RTP/AVP 97 
m=video 6666 RTP/AVP 98 



29-30. SIP 200 (OK) response (from controUer UE to SCC AS) 

The controller UE acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to the SCC AS. 
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A.15.7 Remote party releases media on the controller UE 
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Figure A.15.7: Remote UE releases media on thie Controller UE 



NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalhng flow. 

1. SIP re-INVITE request (Remote Party to intermediate IM CN subsystem entities) - see example in 
table A.15.7-1 

Remote Party sends a SIP re-INVITE request towards Controller UE (UE-1) indicating Media A is to be removed using 
SDP offer. If Media B is to be removed, the re-INVITE request will send to controllee UE (UE-2). 
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Table A.1 5.7-1 : SIP re-INVITE request (Remote Party to intermediate IM CN subsystem entities) 



INVITE <sip:userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - OaOc91e6bf 6> SIP/2 .0 
Via: SIP/2. 0/UDP [5555: :aaa:bbb:ccc:ddd] : 1357 ; comp=sigcomp ; branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route : <sip : pcscf 2 . visited2 . net : 7531 ; Ir ; comp=sigcomp> , <sip : origOscscf 2 . homel . net ; lr> 

P-Asserted- Identity : "David Fan" <sip : userR_publicl@homel . net> 

P-Access -Network- Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From : 

To : 

Call-ID: 

Cseq: 127 INVITE 
Require: sec -agree 
Proxy-Require: sec-agree 
Supported: lOOrel, precondition 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321 ; port- 

c=8642; port-s=7531 

Contact: <sip: userl_public@homel . net> ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 00a0c67t6br4> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Accept: application/sdp , application/3gpp-ims+xml 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : CCC : ddd 
S=- 

c = IN IP6 5555 : :aaa:bbb:CCC:ddd 

t = 

m=audio RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video 4444 RTP/AVP 98 
a=rtpmap:98 MPV/90000 



2. SIP re-INVITE request (intermediate EM CN subsystem entities to SCC AS) 

Intermediate IM CN subsystem entities forward the Re-INVITE request to SCC AS according to standard IMS 
procedure. 

3. SIP re-EWITE request (SCC AS to intermediate IM CN subsystem entities) - see example in table A.15.7-3 

SCC AS removes the Media B information and forwards it towards intermediate IM CN subsystem entities. 

Table A.15.7-3: SIP INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE sip:userlj)ublicl@homel .net SIP/2.0 

Via: SIP/2. 0/UDP sccasl . homel .net ;branch=z9hG4bKnas34r4 . 12 
Max- Forwards : 70 

Route : <sip : termSscscf 2 . homel .net ; lr> 

P-Asserted- Identity: 

P-Access -Network- Info: 

Privacy: 

From: 

To: 

Call-ID: 
Cseq: 

Supported: 
Require : 
Proxy-Require : 
Security- Verify : 
Contact : 
Allow: 
Accept : 
Content-Type : 
Content -Length: (...) 

v=0 

0=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : CCC :ddd 
S = 

C=IN IP6 5555 : :aaa:bbb:CCC:ddd 
t = 

m=audio RTP/AVP 97 
a=rtpmap: 97 PCMU/8000 
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4. SIP re-EWITE request (intermediate EM CN subsystem entities to UE-1) 

Intermediate IM CN subsystem entities forward the re-ESTVITE request to Controller UE according to standard IMS 
procedure. 

5. SIP 200 (OK) response (UE-1 to intermediate EM CN subsystem entities) - see example in table A.15.7-5 

UE-1 response SIP 200 (OK) response with SDP answer. 

Table A.15.7-5: SIP 200 (OK) response (UE-1 to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl .net ;branch=z9hG4bK240f 34 . 3 , SIP/2. 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP 
sccasl .homel .net;branch=z9hG4bKnas34r4 . 12 

From: 

To: 

Call-ID: 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 

Contact : 

Allow: 

Accept: application/sdp; 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IP6 3333 : : eee : f f f : aaa :bbb 
s=- 

c=IN IP6 3333: :eee:fff :aaa:bbb 
t=0 

m=audio RTP/AVP 97 
a=rtpmap:97 PCMU/8000 



6. SIP 200 (OK) response (intermediate EM CN subsystem entities to SCC AS) 

7-8. SIP ACK (SCC AS to UE-1 through intermediate EM CN subsystem entities) 

SCC AS sends an SIP ACK request to Controller UE through intermediate IM CN subsystem entities. 

9. SIP 200 (OK) response (intermediate EM CN subsystem entities to SCC AS) - see example in table A.15.7-9 

SCC AS sends SIP 200 (OK) response with SDP answer indicating Media A is removed to intermediate IM CN 
subsystem entities 
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Table A.15.7-9: SIP 200 (OK) response (UE-1 to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscfl.homel.net;branch=z9hG6bKnas34r4, SIP/2. 0/UDP 
scsf 2 . visited2 . net ; branch=3q5qef sdr62233 . 22 , SIP/2 . 0/UDP 
pcscf2 .visited2 . net ; branch=3q5qef sdr62245 . 12 , SIP/2 . 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 

From : 

To : 

Call-ID: 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 
Contact : 
Allow : 

Accept: application/sdp; 
Content-Type : application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IP6 3333 :: aaa : bbb : ccc : ddd 
s=- 

c=IN IP6 3333 :: aaa : bbb : ccc : ddd 

t=0 

m=audio RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video 6666 RTP/AVP 98 
c=IN IP6 4444 :: aaa : bbb : ccc : ddd 
a=rtpmap:98 MPV/90000 



10. SIP 200 (OK) response (intermediate IM CN subsystem entities to Remote party) 

11-12. SIP ACK (Remote Party to SCC AS through intermediate IM CN subsystem entities) 

Remote Party sends an ACK request to UE-1 through intermediate IM CN subsystem entities which is terminated by 
SCC AS. 

Editor's Note: The SDP in this flow is EES. 

A.1 6 Signalling flows for MSG server assisted mid-call feature 
A. 16.1 Introduction 

The signalling flows in the subclause demonstrate how full duplex session on hold can be transferred together with 
active full duplex session when the MSC server assisted mid-call feature is used. The following signalling flows are 
included: 

subclause A. 16.2 shows an example of CS to PS access transfer with the MSC server assisted mid-call feature, 
subclause A. 16.3 shows an example of PS to CS access transfer with the MSC server assisted mid-call feature. 
The examples assume that: 

the SC UE, the MSC Server enhanced for ICS and the SCC AS support the MSC server assisted mid-call feature; 
the SC UE does not use ICS procedures; and 

the SCC AS is allowed to use the MSC Server assisted mid-call feature according to operator policy. 

A.I 6.2 CS to PS access transfer with MSC server assisted mid-call 
feature 

In the example flow at the figure A. 16.2-1, SC UE A has two ongoing sessions over CS bearer which are anchored at 
SCC AS. The active session X is with UE B, the held session Y is with UE C. The session X and session Y are two 
party sessions. The session Y contains rejected video stream and accepted audio stream. When the SC UE connects to 
an IP-C/VN, it decides to transfer the sessions over the IP -CAN. 
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Figure A.1 6.2-1 : Signalling flow for PS-CS Access Transfer: CS to PS 
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NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalhng flow. 

1. SC UE A has an ongoing active session X with remote UE B and a held session Y with remote UE C 
The calls have been anchored at the SCC AS which is in the HPLMN of originating SC UE A. 

2. SC UE A connects to a new IP-CAN: 

The SC UE A decides to transfer the sessions over the new IP-CAN. The UE A obtains an IP address that it will 
use for the signalling and media. It registers with the S-CSCF over the new IP-CAN using standard registration 
procedure and reserves resources in the new IP-CAN. 

3. SIP INVITE request transferring the active session X (SC UE A to intermediate IM CN subsystem 
entities) - see example in table A. 16.2-3 

The SC UE A sends an initial INVITE request to request the new call replaces the existing call X. 
Table A.1 6.2-3: SIP INVITE request (UE A to intermediate IM CN subsystem entities) 



INVITE sip : domain .xferOsccas . homel . net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp ;branch=z9hG4bKiiashds7 
Max-Forwards: 70 

Route : <sip : pcscf 1 . homel .net:7531;lr>, <sip: origOscscf 1 . homel . net ; lr> 
P- Preferred- Identity : "John Doe" <sip :userl_publicl@homel .net> 
P-Access-Network-Info : IEEE-802 . lib 
Privacy: none 

From: <sip : userl_publicl®homel . net> ; tag=171828 

To: <tel : +l-237-555-2222> 

Call -ID : Cb03a0s0 9a2sdfglkj4 9023 7 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, 199, gruu, norefersub 
Require: sec-agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; portl=7531 
Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lld0-a765- 
00a0c91e6bf 6> ; +g . 3gpp . icsi -ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel " ; +g . 3gpp .mid- call 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Accept: application/sdp; application/3gpp-ims+xml , application/vnd. Sgpp .mid-call+xml 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 
s= 

C=IN IP6 5555 :: aaa : bbb : ccc : ddd 
t = 

m=audio 3456 RTP/AVP 97 96 
a=tcap:l RTP/AVPF 
a=pcfg:l t=l 
b=AS:25.4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a= r tpmap : 9 6 t e 1 ephone - event 
a=maxpt ime : 2 



Contact: contains the feature tag g.3gpp.mid-call as defined in annex C indicating the support for the MSC 
server assisted mid-call feature. 

Accept: contains the MSC Server assisted mid-caU feature MIME type. 

4. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

5. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 
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The SIP INVITE request is forwarded to the SCC AS as the result of the evaluation of iFC. 

6. Remote Leg Update 

The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the Remote Leg. 

7. SIP re-EVVITE request (SCC AS to intermediate EM CN subsystem entities) 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID headers from one side of the B2BUA to the other. The SIP re-lNVlTE request contains the 
SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP INVITE request from the 
UE A (Step 3). 

8. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B) 

The intermediate IM CN subsystem entities forward the SIP re-lNVlTE request to remote UE B. 
9-10: SIP 200 (OK) response (UE B to SCC AS via Intermediate EM CN subsystem entities) 

The UE B generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the SCC AS. 
11-12: SIP ACK request (SCC AS to UE B via Intermediate EM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the remote UE B. 
13-14: SIP 200 (OK) response (SCC AS to UE A via Intermediate EM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request and forwards it to the SC UE A. 
15-16: SIP ACK request (SC UE A to SCC AS via Intermediate IM CN subsystem entities) 

The SC UE A generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the SCC AS 

17. Media patlis between UE A and UE B 

The media path of session X is using the new IP-CAN but the media path of the session Y is stiU using the CS 
bearer. 

18-19. SIP BYE request (SCC AS to MSC Server via intermediate EM CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the CS bearer, by sending a BYE request. 
20-22. ISUP Message 

Upon receiving the DISCONNECT request, the SC UE A relinquishes all resources pertaining to the CS bearer. 

23-24. SEP 200 (OK) response (MSC Server to SCC AS via intermediate EM CN subsystem entities) 

Upon receiving the BYE request over the old IP-CAN, the MSC Server sends a SIP 200 (OK) response over the 
old IP-CAN to the SCC AS. 

25: SIP REFER request (SCC AS to Intermediate EM CN subsystem entities) -see example in table A.16.2-25 

The SCC AS sends SIP REFER request towards UE A inside the dialog created by the message 13. 
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Table A.1 6.2-25: SIP REFER request (SCC AS to IM CN subsystem entities) 



REFER sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2 . 
Via: SIP/2. 0/UDP sip:sccasl.homel.net;branch=z9hG4bk731b8a 
Max-Forwards: 70 

P- Charging- Vector : icid-value= "AyretyU0dm+6O2IrT5tAFrbHLso=023 551024 " ; orig- ioi=homel . net 

From: <tel : +l-237-555-2222>; tag=aasdf gaag 

To: <sip : userl_publicl®homel . net> ; tag=171828 

Call -ID: Cb0 3a0s09a2sdfglkj4 90237 

Cseq: 55998 REFER 

Content-Length: . . . 

Route : <sip : scscf 1 . homel . net ; lr> , <sip :pcscf 1 . homel . net : 7531 ; lr> 

Contact : <sip : sccasl . homel .net ; gr> 

Refer-Sub: false 

Supported: norefersub, gruu 

Ref er-To : <sip : user3_publicl@home3 . net ;gr=urn : uuid : 2ad895 0e-4 8a5-4a74-8d99-ad76cc7f c74?Target- 
Dialog=a84b4c7Ge66710%3Bremote-tag=654364735%3Blocal- 
tag=1928301774&Require=tdialog&From=tel : +1-23 7-555 -llll&To=tel : +1 - 9 8 7 - 654 - 3 2 lO&Content - 
Type=application%2Fsdp&body=v%3D0%0D%0Ao%3D- 

%2 02 987933 G23%2 02 987933 G23%2 0IN%2 0IPe%2 05555 : : ggg : f f f : aaa : bbb%0D%0As%3D- 
%0D%0Ac%3DIN%20IPe%205555 : :ggg: f f f :aaa:bbb%0D%0At%3D0%2 0%0D%0Am%3Dvideo%2 0%2 0RTP%2FAVP%2 
9 8%0D%0Am%3Daudio%2 034 5e%2 0RTP%2FAVP%2 097%2 096%0D%0Ab%3DAS :25 .4%0D%0Aa%3Drtpmap: 97%2 0AMR%0D 
%0Aa%3Dfmtp: 97%2 0mode-set%3D0%2C2%2C5%2C7%3B%20mode-change- 
period%3D2%0D%0Aa%3Dmaxptime : 20%0D%0A> 
Content -Type : application/vnd. Sgpp .mid-call+xml 

<?xml version="l . 0" encoding="UTF-8"?> 
<mid-call/> 



Refer-To: contains UE C contact address and the following URI header fields: 
Target-Dialog: the dialog identifier of the source access leg. 
Require: containing "tdialog" option tag 
From: contains the public user identity of the UE A 
To: contains the public user identity of the UE C 

Content-Type: containing "appUcation/sdp" MIME type of the "body" URI header field 

body: SDP describing the media used in the session 

26. SIP REFER request (intermediate IM CN subsystem entities to UE A) 

The REFER request is forwarded towards the UE A. 

27-28. SIP 202 (Accepted) response (UE A to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the REFER request, the UE A sends a SIP 202 (Accepted) response. 

29. SIP INVITE request transferring the held session Y (SC UE A to intermediate IM CN subsystem entities) 
- see example in table A.16.2-29 

The SC UE A sends an initial INVITE request to request the new call replacing the existing call Y. 
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Table A.1 6.2-29: SIP INVITE request (UE A to intermediate IM CN subsystem entities) 



INVITE sip :user3_publicl@home3 . net ; gr=urn : uuid : 2ad8 95 Oe-4 8a5 -4a74 - 8d99-ad76cc7f c74 SIP/2 . 
Via: SIP/2. 0/UDP [5555: :aaa:bbb:ccc:ddd] : 1357 ; comp=sigcomp ; branch=z9hG4bKjiashds7 
Max-Forwards: 70 

Route : <sip : pcscf 1 . homel . net :7531;lr>, <sip: origOscscf 1 . homel . net ; lr> 
P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 
P-Access-Network-Info : IEEE-802 . lib 
Privacy: none 

From: <tel : +l-237-555-llll>; tag=171828 
To: <tel : +l-987-654-3210> 
Call-ID: asdfqweasas 
Cseq: 127 INVITE 

Supported: lOOrel, precondition, 199, gruu 
Require: sec-agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; portl=7531 
Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765- 
00a0c91e6bf 6> ; +g . 3gpp . icsi -ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel " ; +g . 3gpp .mid- call 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp; application/3gpp-ims+xml 

Target -Dialog: a84b4c76e66710 ; remote-tag=654364 735 ; local -tag=192 83 01774 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s= 

c=IN IP6 5555: : aaa: bbb: ccc: ddd 

t = 

m=video RTP/AVP 98 

m=audio 3456 RTP/AVP 97 96 

b=AS : 25 . 4 

a=curr:qos loca 

a=tcap:l RTP/AVPF 

a=pcfg:l t=ll sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone -event 
a=maxpt ime : 2 
a=sendonly 



Request-URI: contains the remote target URI as received in the Refer-To URI in the REFER request. 

Target-Dialog: contains the dialog identifier as received in the Refer-To URI in the REFER request. 

Contact: contains the feature tag g.3gpp.mid-call as defined in annex C indicating the support for the MSC 
server assisted niid-call feature. 

SDP: All the media are offered with the sendonly directionality. 

30. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 

towards the SCC AS. 

31. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 

The SIP INVITE request is forwarded to the SCC AS as the result of the evaluation of iFC. 

32. Remote Leg Update 

The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the Remote Leg. 

33. SIP re-EWITE request (SCC AS to intermediate EM CN subsystem entities) 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID headers from one side of the B2BUA to the other. The SIP re-INVITE request contains the 
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SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP INVITE request from the 
UE A. 

34. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE C) 

The intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE C. 
35-36: SIP 200 (OK) response (UE C to SCC AS via Intermediate EM CN subsystem entities) 

The UE C generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the SCC AS. 
37-38: SIP ACK request (SCC AS to UE C via Intermediate EM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the remote UE C. 
39: SIP 200 (OK) response (SCC AS to Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request and forwards it to the SC UE A. 
40: SIP 200 (OK) response (Intermediate EM CN subsystem entities to UE A) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request and forwards it to the SC UE A. 
41-42: SIP ACK request (SC UE A to SCC AS via Intermediate EM CN subsystem entities) 

The SC UE A generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the SCC AS 
43. Media paths between UE A and UE B 

The media paths of session X and session Y are using the new IP -CAN but the the CS bearer is still not released. 
44-45. SIP BYE request (SCC AS to MSC Server via intermediate EM CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the CS bearer, by sending a BYE request. 
46-48. ISUP Message 

Upon receiving the DISCONNECT request, the SC UE A relinquishes all resources pertaining to the CS bearer. 
49-50. SIP 200 (OK) response (MSC Server to SCC AS via intermediate EM CN subsystem entities) 
51. Media patlis between UE A and UE B 

The media paths of session X and session Y are using the new IP-CAN. 

A. 16.3 PS to CS access transfer with MSC server assisted mid-call 
feature 

In the example flow at the figure A.16.3-1, SC UE A has two ongoing sessions over PS bearer which are anchored at 
SCC AS. When both sessions were established the SC UE and the SCC AS included the feature tag g.3gpp.mid-call as 
specified in annex C into the Contact headers. The active session X is with UE B, the held session Y is with UE C. The 
session X and session Y are two party sessions. The session Y contains a rejected video stream and an accepted audio 
stream. When the SC UE attaches to the CS domain, it decides to transfer the sessions over the CS bearer without using 
the ICS capability. 
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Figure A.1 6.3-1 : Signalling flow for PS-CS access transfer: PS-CS 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalUng flow. 
1. SC UE A is on an active session X witli UE B and a lield session Y with UE C: 
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There is an ongoing IP bearer between the SC UE and the remote UE B and another IP bearer between the SC 
UE and the remote UE C. Both sessions are anchored at SCC AS. 

2. SC UE A attaches to the CS domain 

The SC UE attaches to the CS domain and decides to transfer the sessions over the CS bearer. 

3. CC SETUP messages 

Editor's note: it is EES how to ensure that the UE and the MSC Server would use the same transaction identifers for 
the held session 

4. SIP INVITE request transferring the active session X (MSC Server to Intermediate IM CN subsystem 
entities) -see example in table A.16.3-4 

Table A.16.3-4: SIP INVITE request (MSC Server to intermediate IM CN subsystem entities) 



INVITE tel : +1-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mscl . homel . net ;branch=z9hG4bk731b87 
Max-Forwards: 70 

P-Asserted- Identity : <tel :+l-237-555-llll> 

P- Charging- Vector : icid-value= " AyretyU0dm+6O2IrT5tAFrbHLso=023 5 51024 " ; orig- ioi=homel . net 
Privacy: none 

From: <tel : +1-237- 555- 1111> ; tag=171828 
To: <tel : +l-237-555-3333> 
Call -ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu, 199, norefersub 

Accept -Contact : * ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
P- Asserted- Service : urn : urn- 7 : 3gpp- service . ims . icsi . mmtel 

Contact : <sip : userl_publicl®homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765- 
00a0c91e6bf 6> ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7%3gpp- 
service . ims . icsi . mmtel " ; +g . 3gpp . ics= " server" ; +g . 3gpp . mid- call 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content-Length: (...) 

Accept: application/sdp; application/3gpp- ims+xml , application/vnd . 3gpp . mid-call+xml 



v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : eee 
s = 

c=IN IP6 5555 :: aaa : bbb : ccc : eee 
t = 

m=audio 3456 RTP/AVP 97 96 
a=tcap:l RTP/AVPF 
a=pcfg:l t=l 
b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode- change -period=2 
a=rtpmap:96 telephone -event 
a=maxptime : 2 



Request-URI: contains the IMRN, as obtained from CS networks signalUng. 
SDP: The SDP contains preconfigured set of codecs supported by the MSC Server. 

Contact: contains the feature tag g.3gpp.mid-call as defined in annex C indicating the support for the MSC 
server assisted mid-call feature. 

Accept: contains the MSC Server assisted mid-call feature MIME type. 

5. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 
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6. SIP INVITE request (Intermediate IM CN subsystem entities to SCC AS) 

7. Remote Leg Update 

The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the Remote Leg. 

8. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS acting as a routing B2BUA generates a SIP re-INVITE request based upon the received SIP 
INVITE request and the information previously stored against this session and routes it towards UE B via the 
intermediate IM CN subsystem entities. 

9. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B) 

Intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE B. 

10. SIP 200 (OK) response (UE B to intermediate IM CN subsystem entities) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE B has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

11. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SIP re-INVITE request to 
the SCC AS in the originating network. 

12-13. SIP ACK request (SCC AS to UE B via IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request 
to the remote UE B. 

14-15. SIP 200 (OK) response (SCC AS to MSC Server via IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request, and forwards the SIP 200 (OK) 
response towards the MSC Server. 

Editor's note: it is EES how the session state information is transported to the MSC Server 

16. ISUP CONNECT message (MSC Server to SC UE A) 

Based on the received session state information, the MSC Server associates transaction identifier value of with 
UE B and associates transaction identifier value of 1 with UE C. 

17. ISUP CONNECT Response message (SC UE A to MSC Server) 

18-19. SIP ACK request (MSC Server to SCC AS via IM CN subsystem entities) 

The MSC Server generates the SIP ACK request to the SIP 200 (OK) response, and forwards it to the SCC AS. 
20. Media paths between SC UE A and UE B: 

The CS bearer is setup while the PS bearers are still existing. 

21-22: SIP BYE request (SCC AS to SC UE A via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg of the session X, which was using the old IP-CAN, by sending a 
BYE request to the UE A. 

23-24. SIP 200 (OK) response (SC UE A to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the BYE request over the old IP-CAN, the SC UE A sends a SIP 200 (OK) response over the old 
IP-CAN to the SCC AS. Subsequently, the SC UE A relinquishes all resources pertaining to the old IP -CAN. 

25. Media paths between SC UE A and UE B 

The session X is transferred from PS bearer to CS bearer, but the session Y is still at the PS bearer. 
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26. SIP REFER request (SCC AS to EM CN subsystem entities) -see example in table A.16.3-26 

The SCC AS sends SIP REFER request towards MSC Server inside the dialog created by the the message 14. 

Table A.16.3-26: SIP REFER request (SCC AS to IM CN subsystem entities) 



REFER sip : user l_publiclahomel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2 . 
Via: SIP/2. 0/UDP sip : sccasl . homel .net ;branch=z9hG4bk731b8a 
Max - Forwards : 7 

P- Charging- Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024 " ; orig-ioi=homel .net 

To: <tel:+l-237-555-llll>;tag=17182 8 

From: <tel : +1-237- 555- 3333 >; tag=sdfsdf 

Call -ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 55998 REFER 

Content-Length: 125 

Route : <sip:scscfl. homel .net ; lr> 

Refer-Sub: false 

Supported: norefersub, gruu 

Contact: sip : sccasl . homel . net 

Ref er-To : <sip : user3_publicl@home3 . net ;gr=urn : uuid : 2ad8 95 0e-4 8a5-4a74-8d9 9-ad7Scc7f c74?Target- 
Dialog=ksdj f hwrklf %3Bremote-tag=G7 6 72 3 5 65%3Blocal-tag=4 541B4 54&Require = tdialogS:From=tel : + l- 
237-555-llll&To=tel : +l-9B7-G54-3210&Content-Type=application%2Fsdp&body=v%3D0%0D%0Ao%3D- 
%2 02 987933 G23%2 02 987933 G23%2 0IN%2 0IPG%2 05555 : : ggg : f f f : aaa : bbb%0D%0As%3D- 
%0D%0Ac%3DIN%20IPG%205555 : :ggg: f f f :aaa:bbb%0D%0At%3D0%2 0%0D%0Am%3Dvideo%2 0%2 0RTP%2FAVP%2 
9 8%0D%0Am%3Daudio%2 034 5G%2 0RTP%2FAVP%2 097%2 096%0D%0Ab%3DAS : 25 . 4%0D%0Aa%3Drtpmap : 97%2 0AMR%0D 
%0Aa%3Dfmtp: 97%2 0mode-set%3D0%2C2%2C5%2C7%3B%20mode-change- 
period%3D2%0D%0Aa%3Dmaxptime : 20%0D%0A> 

Content -Type : application/vnd. 3gpp .mid-call+xml 

<?xml version="l . 0" encoding="UTF-8"?> 
<mid-call/> 



Refer-To: contains UE C contact address and the following URI header fields: 
Target-Dialog: the dialog identifier of the source access leg. 
Require: containing "tdialog" option tag 
From; contains the public user identity of the UE A 
To: contains the public user identity of the UE C 

Content-Type: containing "apphcation/sdp" MIME type of the "body" URI header field 
body: SDP describing the media used in the session 
27: SIP REFER request (intermediate IM CN subsystem entities to MSC Server) 

The REFER request is forwarded towards the MSC Server. 

28-29. SIP 202 (Accepted) response (MSC Server to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the REFER request, the MSC Server sends a SIP 202 (Accepted) response. 

30. SIP INVITE request for the held session Y (MSC Server to Intermediate IM CN subsystem entities) -see 
example in table A.16.3-30 
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Table A.1 6.3-30: SIP INVITE request (MSG Server to intermediate IM CN subsystem entities) 



INVITE sip : user3publicl@home3 . net ;gr=urn : uuid : 2ad8950e-4 8a5-4a74-8d99-ad76cc7f c74 SIP/2 . 
Via: SIP/2. 0/UDP mscl .homel .net;branch=z9hG4bk731b87 
Max-Forwards: 70 

P- Asserted- Identity: <tel : +1-237- 555- 1111 > 

P -Charging- Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024 " ; orig-ioi=homel .net 

Privacy: none 

From: <tel : +1-237- 555 - 1111> ; tag=171828 
To: <tel : +l-987-654-3210> 
Call-ID: asdfgqwerq 
Cseq: 1275 INVITE 

Supported: lOOrel, precondition, 199, gruu 

Accept -Contact : * ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7% 3gpp- service . ims . icsi . mmtel " 
P- Asserted- Service : urn : urn- 7 : 3gpp- service . ims . icsi . mmtel 

Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765- 
00a0c91e6bf 6> ; +g . 3gpp . icsi -ref = "urn%3Aurn- 7%3gpp- 
service . ims . icsi . mmtel " ; +g . 3gpp . ics= " server" ; +g . 3gpp . mid- call 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Target-Dialog : ksdj f hwrklf ; remote-tag=676723565 ; local-tag=45418454 
Require: tdialog 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : CCC : eee 
S = 

c=IN IP6 5555 :: aaa : bbb : CCC : eee 

t = 

m=video RTP/AVP 98 
m=audio 3456 RTP/AVP 97 96 
a=tcap : 1 RTP/AVPF 
a=pcfg:l t=l 
b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 20 
a=sendonly 



Request-URI: contains the remote target URI as received in the Refer-To URI in the REFER request. 

Target-Dialog: contains the dialog identifier as received in the Refer-To URI in the REFER request. 

Contact: contains the feature tag g.Sgpp.mid-call as defined in annex C indicating the support for the MSG 
server assisted mid-call feature. 

SDP: The SDP contains preconfigured set of codecs supported by the MSG Server. AH the media are offered 
with the sendonly directionality. 

31. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SG user and as a result routes the SIP INVITE request 

towards the SCC AS. 

32. SIP INVITE request (Intermediate IM GN subsystem entities to SGG AS) 

33. Remote Leg Update 

The SGG AS performs the Remote Leg update by sending the SIP re-INVITE request towards the Remote Leg. 

34. SIP re-EWITE request (SCC AS to intermediate EM CN subsystem entities) 

The SGG AS acting as a routing B2BUA generates a SIP INVITE request based upon the received SIP INVITE 
request and the information previously stored against this session and routes it towards UE C via the 
intermediate IM CN subsystem entities. The SIP re-lNVlTE request contains the SDP offer that is identical to 
the SDP offer that the SGG AS received in the initial SIP INVITE request from the UE A. 
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35. SIP re-EVVITE request (Intermediate EM CN subsystem entities to UE C) 

Intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE C. 

36. SIP 200 (OK) response (UE C to intermediate EM CN subsystem entities) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE C has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 

SDP answer indicates that the resources are available. 

37. SIP 200 (OK) response (intermediate EM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SIP re-INVITE request to 

the SCC AS in the originating network. 

38-39. SIP ACK request (SCC AS to UE C via EM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request 
to the remote UE C. 

40. SIP 200 (OK) response (SCC AS to IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request, and forwards the SIP 200 (OK) 
response towards the MSC Server. 

41. SIP 200 (OK) response (Intermediate IM CN subsystem entities to MSC Server) 

Intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SIP INVITE request to MSC 
Server. 

42-43. SIP ACK request (MSC Server to SCC AS via EM CN subsystem entities) 

The MSC Server generates the SIP ACK request to the SIP 200 (OK) response, and forwards it to the SCC AS. 

44. Media paths between SC UE A and UE B: 

The CS bearer and PS bearers for both the sessions are established but there is still the original IP bearer for the 
held session Y. 

45-46; SIP BYE request (SCC AS to SC UE A via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg of the session Y, which was using the old IP-CAN, by sending a 
BYE request to the UE A. 

47-48. SIP 200 (OK) response (SC UE A to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the BYE request over the old IP-CAN, the SC UE A sends a SIP 200 (OK) response over the old 
IP-CAN to the SCC AS. Subsequently, the SC UE A relinquishes all resources pertaining to the old IP-CAN. 

49. Media paths between SC UE A and UE B 

Both sessions X and Y are transferred from PS bearer to CS bearer. 

A.1 7 Signalling flows for SRVCC session transfer for IMS 
emergency session 

A.1 7.1 Introduction 

The signalhng flows for SRVCC session transfer for IMS emergency session demonstrate how an IMS emergency 
session is transferred from PS network to CS network using SRVCC procedure. The following signalhng flow is 
included: 
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subclause A. 17.2 shows an example when a UE initiating an emergency session in IMS for the case that the UE 
is not in limited service mode ;and 

subclause A. 17.3 shows an example when the emergency session need to transfer from PS to CS using SRVCC 
procedure for the case that the UE is not in limited service mode. 



A.17.2 UE initiating an emergency session in IIVIS 

The signalhng flows shown in figure A.17.2-1 describes the UE initiating an IMS emergency session procedure for the 
case that the UE is not in Umited service mode. The flow illustrates the anchoring of the session at the EATF. 



UEA 



P-CSCF 



E-CSCF 



EATF 



-1. INVITE(sos-urn)- 



-11. SIP 200 (OK) INVITE 

12. ACK ► 



2. SIP INVITE 

(sos-urn) 



^10. SIP 200 (0K)_ 

INVITE 



-13. ACK- 



3. SIP INVITE 

(sos-urn) 



4. Anchor Emergency 
Session 



5. SIP INVITE_ 
' (sos-urn) 



-6. SIP INVITE (to PSAP)- 



7. SIP 

"200 (OK) INVITE 



8. SIP 
200 (OK) invite" 

9. SIP 200 (OK) 

INVITE 



-14. ACK- 



NOTE I 
NOTE 2 
NOTE 3 



Figure A.17.2-1: Signaiiing fiow for UE initiating an emergency session in ilUIS 

For clarity, the SIP 100 (Trying) responses are not shown in the signalhng flow. 
For clarity, the SIP 180 (Ringing) response is not shown in the signalling flow. 
For clarity, the precondition mechanism is not shown in the signalling flow. 



1. SIP EVVITE request (UE A to P-CSCF) see example in table A.17.2-2 
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INVITE urn : service : SOS . fire SIP/2.0 

Via: SIP/2. 0/UDP [5555: :aaa:bbb:ccc:ddd] : 1357 ; comp=sigcomp ;branch=z9hG4bKjiashds7 
Max-Forwards: 70 

Route : <sip:pcscf.visitl. net : 7531 ; Ir ; comp=sigcomp> 
P- Preferred- Identity : <sip : userl_publicl@homel . net > 

P-Access-Network-Info : 3GPP-UTRAN-FDD; utran-cell-id-3gpp=234151D0FCEll 
Privacy: none 

From : <sip : userl_publicl®homel . net > ; tag=17182 8 

To: <urn : service : SOS . fire> 

Call -ID: Cb03a0s09a2sdfglkj4903 3 3 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, 199, gruu 
Accept : application/ sdp, application/ 3gpp-ims+xml 

Require: sec -agree 
Proxy-Require: sec-agree 

Accept -Contact : * ; +g . 3gpp . icsi-ref= "urn%3Aurn- 7%3gpp- service . ims . icsi . mmtel " 
P- Preferred -Service : urn : urn- 7 : 3 gpp- service . ims . icsi . mmtel 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac- sha- 1- 96 ; spi=87654321 ; port=7531 
Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid :f81d4fae-7dec-lld0-a765- 

00a0c91e6bf 6> ; +g . 3gpp . icsi -ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
Geolocation : <sips : 3sdef rhy2 j j 7@lis . atlanta . example . com> ; inserted- 

by= " sip : userl_publicl(ahomel . net " ; routing-allowed= "yes " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

0=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : CCC : ddd 
s= 

c= IN IP6 5555 : :aaa:bbb:ccc:ddd 
t = 

m=audio 34 RTP/AVP 98 

a=curr: qos local none 

a=curr: qos remote none 

a=des: qos mandatory local sendrcv 

a=des : qos mandatory remote sendrcv 

a= inactive 



Contact: contains the "gr" parameter formed from an IMEI URN as specified in 3GPP TS 24.229 [2] 
2. SIP EVVITE request (EATF to E-CSCF) see example in table A.17.2-3 
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INVITE urn : service : SOS . fire SIP/2.0 

Via: SIP/2. 0/UDP pcscf .visitl.net;branch=z9hG4bK240f34.1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 6 9 

Route : <sip:ecscf.visitl. net ; Ir ; > 

Record- Route : <sip : pcscf . visit 1 . net ; lr> 

P- Preferred- Identity : 

P -Access -Network- Info : 

Privacy: 

From : 

To : 

Call-ID: 
Cseq : 

Supported : 
Accept : 
Require : 
Proxy-Require : 
Accept-Contact : 
P-Pref erred-Service : 
Security-Verif y : 
Contact : 
Geolocation : 
Allow : 

Content-Type : 
Content -Length: (...) 

v= 
o= 
s= 
c= 
t= 

m= 

a=curr : 
a=curr : 
a=des : 
a=des : 
a= 



3. SIP EVVITE request (E-CSCF to EATF) see example in table A.17.2-4 
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Table A.I 7.2-4: SIP INVITE request 



INVITE urn : service : SOS . fire SIP/2.0 

Via: SIP/2. 0/UDP esccas . visitl . net ;branch=z9hG4bK871yl2 . 1 , SIP/2. 0/UDP 
pcscf . visitl .net ;branch=z9hG4bK24 0f 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 

Max- Forwards : 68 

Route : <sip:esccas. visitl. net ; Ir ; > 

Record- Route : <sip:ecscf. visitl. net ;lr>,<sip: pcscf. visitl. net ; lr> 

P- Preferred- Identity : 

P-Access-Network-Inf o : 

Privacy : 

From : 

To : 

Call-ID: 
Cseq : 

Supported : 
Accept : 
Require : 
Proxy-Require : 
Accept-Contact : 
P-Pref erred-Service : 
Security-Verify : 
Contact : 

Geolocation : <sips : 3sdef rhy2 j j 7@lis . atlanta . example . com> ; insert ed- 

by= " sip : userl_publicl@homel . net " ; routing-allowed= "yes " ; used- for -routing 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 
t= 
m= 
a= 
a= 
a= 
a= 
a= 



4. EATF anchors the emergency session 

The EATF (acting as a routing B2BUA) anchors the emergency session, i.e. the EATF is inserted in the 
signalling path which invokes a 3pcc for enablement of Access Transfers 

5. SIP INVITE request (EATF to E-CSCF) see example in table A.17.2-5 

The EATF acting as a routing B2BUA, generates a SIP INVITE request based upon the received SIP INVITE 
request and the information previously stored against this session and routes it towards PSAP via the 
intermediate IM CN subsystem entities. 
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INVITE urn : service : SOS . fire SIP/2.0 

Via: SIP/2. 0/UDP esccas .visitl .net;branch=z9hG4bKnas34r5 
Max- Forwards : 67 

Route : <sip:ecscf. visitl. net : 7531 ; Ir ; comp=sigcomp> 

Record- Route : <sip:ecscf. visitl. net ; lr> 

P- Preferred- Identity: <sip :userl_publicl@homel . net > 

P- Access -Network- Info: 3GPP-UTRAN-FDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From : <sip : userl_publicl@homel .net> ; tag=17182 8 

To: <urn : service : SOS . fire > 

Call -ID: Cb0 3a0s09a2sdfglkj4 90333 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, 199, gruu 
Accept : application/sdp , application/3gpp- ims+xml 
Require: sec-agree 
Proxy-Require: sec-agree 

Accept -Contact : * ; +g . 3gpp . icsi-ref= "urn%3Aurn- 7%3gpp- service . ims . icsi .mmtel " 
P- Preferred- Service : urn : urn- 7 : 3 gpp- service . ims . icsi . mmtel 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; port=7531 

Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765- 
00a0c91e6bf 6> ; +g . 3gpp . icsi -ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 

Geolocation : <sips : 3sdef rhy2 j j 7@lis . atlanta . example . com> ; insert ed-by= " 
sip : userl_publicl@homel . net "Crout ing-allowed= "yes " ; used- for- routing 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s= 

c= IN IP6 5555: : aaa: bbb: ccc: ddd 

t = 

m=audio 3400 RTP/AVP 98 

a=curr: qos local none 

a=curr: qos remote none 

a=des: qos mandatory local sendrcv 

a=des: qos mandatory remote sendrcv 

a= inactive 



6. SIP INVITE request (E-CSCF to PSAP) 
E-CSCF routes the SIP INVITE request to the PS/VP. 

7. SIP 200(OK) response (PSAP to E-CSCF) see example in table A.17.2-6 
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Table A.1 7.2-6: SIP 200 OK 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP ecscf .visitl .net;branch=z9hG4bKnas34r5 
Max-Forwards: 67 

Record- Route : <sip: ecscf. visitl. net ;lr>,<sip:pcscf. visitl. net ; lr> 
Privacy: none 

From : <sip :userl_publicl®homel . net > ; tag=17182 8 
To: < urn : service : SOS . fire > ; tag=232456 
Call-ID: 
Cseq : 

Require: lOOrel, precondition, 199, gruu 
Contact: <sip : mgcf . visitl . net > . 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 
s= 

c= IN IP6 5555: :fff:eee : ccc :ddd 
t=0 

m=audio 34 RTP/AVP 98 

a=curr: qos local none 

a=curr: qos remote none 

a=des: qos mandatory local sendrcv 

a=des: qos mandatory remote sendrcv 

a=inactive 

8-9. SIP 200 OK response (E-CSCF to EATF and to E-CSCF) 

E-CSCF forwards the 200 OK. 
10-11. SIP 200 OK response (E-CSCF to UE A) see example in table A.17.2-7 

Table A.17.2-7: SIP 200 OK 



SIP/2.0 200 OK 
Via: 

Max-Forwards: 65 
Record-Route : 
Privacy: 
From : 
To : 

P-Asserted- Identity: tel : 911;context="+l 

Call-ID: 

Cseq : 

Require : 

Contact : 

Allow : 

Content -Type : 
Content -Length: 

v= 
o= 
s= 
c= 
t= 

m= 
a= 
a= 
a= 
a= 
a= 



12. ACK request 

UE A responds to the 200 OK response with an ACK request. 
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A.1 7.3 Session transfer for emergency session using SRVCC 
procedure: PS-CS 

In the example in figure A.17.3-1, UE A (which has a vahd subscription, is authenticated and authorized for PS service 
and is normal attached to the network) has an ongoing emergency session with a PSAP using a PS bearer which is 
anchored at EATF. Based upon measurement reports sent from the UE to E-UTRAN, the source E-UTRAN decides to 
trigger a SRVCC handover to CS access. 



UE A 



Interworking 
Entities 



P-CSCF 



I-CSCF 



EATF 



E-CSCF 



1. UE A is on an emergency call with PSAP through PS network. Call is anchored at EATF. 



2. UE A sends measurement reports to 
E-UTRAN, and the source 
E-UTRAN decides to trigger an SRVCC 
handover to the UTRAN/GERAN 



■1. PS beared 



-3.1NV1TE(E-STN-SR)- 



-13. SIP 200 (OK) iNviTE- 
14. SIP ACK 



-18. SIP BYE- 
I 



-19. SIP 200 (OK)- 



■22a.CS bearer- 
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(E-STN-SR) ' 



5 Remote leg Update 



12. SIP 
200 (OK) INVITE 



-15. SIP ACK-i 



—10. SIP ACK-l 



-17. SIP BYE- 



-20. SIP 200 (OK)- 



-22b. PS bearep- 



6. SIP 
'relNVlTE 



9. SIP 200 (OK) 

relNVITE 



-16. SIP BYE-l 




7. SIP 
relNVlTE"*' 
_ 8. SIP 200 _ 

(OK) relNVITE 



11. SIP ACK- 



Figure A.17.3-1 Signalling flow for emergency session transfer using SRVCC procedure 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalUng flow. 

1. UE A is on an active emergency session with a PSAP 

There is an ongoing IP bearer between the UE A and the remote end PSAP. The call is achored at EATF. 

2. SC UE A attaches to the CS domain 
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UE A sends the measurement reports to E-UTRAN, and the source E-UTRAN decides to trigger an SRVCC 
handover to CS access. The MSC Server initiates the session transfer with the E-STN-SR, refer to 
3GPPTS 23.237 [9]. 

3. SIP EVVITE request (Interworking entities to Intermediate EM CN subsystem entities) -see example in 
table A.17.3-2 

Table A.17.3-2: SIP INVITE request (interworking entities to intermediate IM CN subsystem entities) 



INVITE tel: +1-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mscl . visitl .net ;branch=z9hG4bk731b87 
Max- Forwards : 70 

Route : <sip:icscfl. visitl .net ; lr> 
P-Asserted- Identity: <tel : +1-23 7-555 -1111> 

P- Charging- Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024 " ;orig-ioi=visitl .net 
Privacy: none 

From: <tel : +1-23 7-555 -1111> ; tag=17182 8 
To: <tel: +l-237-555-3333> 
Call- ID: Cb03a0s09a2sdfglkj490334 
Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu 

Accept -Contact : * ; +g . 3gpp . icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 
P-Asserted- Service : urn: urn- 7 : 3gpp- service . ims .icsi .mmtel 

Contact : <sip:mscl . homel . net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 > ; +g. 3gpp. icsi- 
ref = "urn%3Aurn- 7%3gpp- service . ims . icsi . mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 
Content-Type: application/sdp 
Content -Length : (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : eee 
s= 

c=IN IP6 5555 :: aaa: bbb: ccc : eee 
t=0 

m=audio 3456 RTP/AVP 97 96 
a=tcap:l RTP/AVPF 
a=pcfg:l t=l 
b=AS:25.4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxpt ime : 2 



Request-URI: contains the E-STN-SR, as routed to the EATF 

SDP: The SDP contains preconfigured set of codecs supported by the MGW. 

Contact: contains the "gr" parameter formed from an IMEI URN as specified in 3GPP TS 24.229 [2] 

4. SIP INVITE request 

The I-CSCF routes the INVITE request directly to the EATF by using the procedure defined in 
3GPP TS 23.228 [15] for PSI based application Server termination. 

NOTE 2: The use of indirect routing for PSI based Application Server Termination as described in 

3GPP TS 23.228 [15] in subclause 5.7.6 cannot be used for routing the INVITE request to the EATF. 

5. Remote Leg Update 

The EATF based on the content of the "gr" parameter in the Contact header field correlates the SIP INVITE 
request to the local and remote call legs of the existing session between the UE A and the remote end. The EATF 
performs the Remote Leg update by sending the SIP re-INVITE request towards the Remote Leg. 

6. SIP re-EWITE request (EATF to intermediate IM CN subsystem entities) -see example in table A.17.3-3 
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TheEATF acting as a routing B2BUA generates a SIP INVITE request based upon the received SIP INYITE 
request and the information previously stored against this session and routes it towards PSAP via the 
intermediate IM CN subsystem entities. 

Table A.17.3-3: SIP re-INVITE request (SCC AS to intermediate IIUI CN subsystem entities) 



INVITE urn : service : SOS . fire SIP/2.0 

Via: SIP/2. 0/UDP esccasl .homel .net ;branch=z9hG4bKnas34r5 

Max- Forwards : 6 8 

Route: <sip : ecscfl . homel . net : lr> 
P-Asserted-Identity : <tel: +l-237-555-llll> 

P- Charging- Function- Addresses : ccf=[5555::b99:c88:d77:e66]; ccf = [5555 : :a55 :b44 :c33 :d22] ; 

ecf = [5555 : : If f : 2ee : 3dd: 4ee] ; ecf= [5555: : 6aa : 7bb : 8cc : 9dd] 
P -Charging- Vector : icid-value="BzyretyU0dm+602IrT5tAFrbHLso=023551034 " ; orig-ioi="type3homel .net " 

Privacy: none 

From : <sip : userl_publicl@homel . net > ; tag=17182 8 
To : <urn: service : sos . f ire> ; tag=2324 56 
Call- ID: Cb03a0s09a2sdfglkj490333 
Cseq : 

Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a76 5- 
00a0c91e6bf6>;+g. 3gpp .icsi-ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
Allow: 

Content-Type: Content-Length: 
v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa: bbb: ccc : eee 

t = 

m=audio 3456 RTP/AVPF 97 96 
b=AS:25.4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 2 
m=message TCP/MSRP 98 
a=accept- types : text/plain 



7. SIP re-INVITE request (E-CSCF to PSAP) 
E-CSCF forward the SIP re-INVITE request to the PSAP. 

8. SIP 200 (OK) response (PSAP to E-CSCF) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the PSAP has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

9. SIP 200 (OK) response (E-CSCF to EATF) 

E-CSCF forward the SIP 200 (OK) response to the SIP re-INVITE request to the EATF in the originating 
network. 

10-11. SIP ACK request (EATF to PSAP via EM CN subsystem entities) 

The EATF generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request to 
the PSAP. 

12-13. SIP 200 (OK) response (EATF to interworking entities via IM CN subsystem entities) 

The E- SCC AS generates the SIP 200 (OK) response to the SIP INVITE request, and forwards the SIP 200 
(OK) response to the interworking entities. 

14-15. SIP ACK request (interworking entities to EATF via EM CN subsystem entities) 

The interworking entities generate the SIP ACK request to the SIP 200 (OK) response, and forward the SIP ACK 
request to the EATF. 
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16-18: SIP BYE request (EATF to UE A via intermediate EM CN subsystem entities) 

The EATF terminates the source access leg, which was using the old IP-CAN, by sending a BYE request to the 

UE A. 

19-21. SIP 200 (OK) response (UE A to E- SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the BYE request over the old IP-CAN, the UE A sends a SIP 200 (OK) response over the old IP- 
CAN to the EATF. Subsequently, the UE A relinquishes all resources pertaining to the old IP -CAN. 

22a. CS bearer establisliment (interworking entities to UE A) 

22b. IP bearer establishment (interworking entities to PSAP) 
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Annex B (informative): 
Collaborative session state model 

This annex describes a state model applicable for the UEs involved in collaborative session handling for inter-UE 
transfer, listing possible states and state transitions. Some procedures in collaborative session handling lead to 
synchronous state transitions of two different UEs. 

Editor's note: the state model is not intended directly for implementation; rather it is provided as an abstraction and 
condensed view of what is specified in procedures in the main body of this specification 
(clauses 16 to 19). The final status and placement within this specification of contents currently 
documented in this annex is PES. 

Figure B-1 visualizes the states and state transitions for UEs within a collaborative session for inter-UE transfer. 
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Figure B-1 : State model for UEs in collaborative session for inter-UE transfer 

The description of the possible states of a UE within a collaborative session is given in table B-1. 
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Table B-1 : States of UEs in collaborative session for inter-UE transfer 



State 


Description 


NULL 


No participation in a collaborative session. 


Controlling Mode 


The UE participates in a collaborative session and performs the role of a 
controller UE, but has no media with the remote leg established. 


Controlling Mode (with media) 


The UE participates in a collaborative session and performs the role of a 

controllling UE; it has at least one media with the remote leg established. 


Controlled Mode 


The UE participates in a collaborative session and performs the role of a 
controllee UE; it has at least one media with the remote leg established. 



NOTE 1 : in this release the state "Controlled Mode" without media is not possible. 

NOTE 2: the state "Controlled Mode" does not require any specific functionality for an IMS UE. 
The possible state transitions and their triggering procedures are listed in table B-2. 
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Table B-2: State transitions of UEs within collaborative session for inter-UE transfer 



Source 
state 


Target state 


State Transition 


Nr. 


Description 


Coupled 
with 




Controlling 
Mode 


transfer media 
(outbound, all) 


1 


The UE transfers all media to a controllee UE, but 
l<eeps control of the collaborative session. 


3 


NULL 


Controlling 
Mode (witli 
media) 


transfer media 
(outbound) 


2 


The UE transfers (not all) media to a controllee UE, 
and keeps control of the collaborative session. 


3 




Controlled 
Mode 


transfer media 
(inbound, first) 


3 


The UE gets media transferred from another UE, 
which keeps collaborative session control. 


1 or 2 




NULL 


transfer media 

(inbound, last) 


4 


The UE transfers from another UE the last media of 

the collaborative session back to itself. 


18 






collaborative 
session release 


5 


^Fl 'Xl Xl X X ■ 1 1 /I xl 

The session with the remote party is released (by the 
controlling UE, the NW or the remote party). 


19 


Control- 
ling IVIode 


Controlling 
Mode 


monitoring 


6 


The controlling UE requests monitoring status of the 
collaborative session from one or more controllee 
UEs. 


22 




Controlling 
Mode (with 
media) 


add media 


7 


X II" 1 If II 1' / 'xl xl X _x \ 

The controlling UE adds media (with the remote party) 
onto itself; other UEs and their media are not affected. 






transfer media 
(first) 


8 


^Fl 1 1 l~~ X £ t' /'M. £' A.\ £ Xxl 

The UE transfers media (its first) from one of the 
controllee UEs back to itself. 


18 or 23 




NULL 


collaborative 
session release 


9 


See nr. 5. 


20 




transfer media 
(last) 


10 


The controlling UE transfers its last media to a 

X II II l~~ 1 1 1 'X' III 1 

controllee UE and additionally hands over 
collaborative session control. 








transfer media 
(outbound, all) 


11 


The controlling UE transfers (all) media to a controllee 
and keeps collaborative session control. 


23 


Control- 
ling Mode 
(witli 
media) 


Controlling 
Mode 


release media 
(last) 


12 


The controlling UE releases its last media, but other 

1 ' ' "X 1 X 1 II l~~ 'X 1 ' X 1 III X' 

media remain with other UEs within the collaborative 
session. No change of collaborative session control, 
which remains with the currently controlling UE. 






monitoring 


13 


See nr. 6. 


22 




modify media 


14 


The controlling UE modifies its own media, other UEs 
and their remain unaffected. 






Controlling 
Mode (with 
media) 


transfer media 
(outbound, non- 
last) 


15 


The UE transfers media to one of the controllee UEs 

xl X 1' Ixl 1 III X' 

at least one media, and thus also collaborative 
session control remains with it. 








transfer media 
(intbound, non- 
first) 


16 


Thp I IF trpn^fprci mprlifl frnm nnp nf thp mntrnllpp 

UEs back to itself. 


18 or 23 




void 


void 


17 


void 








transfer media 
(outbound, last) 


18 


The controllee UE gets its last media removed by the 
controlling UE. As a consequence, the UE is no longer 
participant of the collaborative session. 


16 or 8 




NULL 


release media 
(last) 


19 


As nr. 1 8, but removal of media instead of transfer. 


4 






collaborative 
session release 


20 


See nr. 5. 


5 




void 


void 


21 


void 




Controlled 
Mode 




report status 


22 


The UE reports the status of is established media to 
the controlling UE. 


6 




Controlled 


transfer media 
(inbound or 
outbound, non- 
first, non-last) 


23 


The controllee gets media transferred to or from 
another UE (controlling or controllee) in the 
collaborative session, dictated by the controlling UE. 


11 




Mode 


release media 
(non-last) 


24 


Media on the UE is released, either by the UE itself or 
dictated by the controlling UE; at least one media is 

kept. 








modify media 


25 


Media on the UE is modified, either by the UE itself or 
dictated by the controlling UE; other UEs are not 
affected. 
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Annex C (normative): 

Media feature tags defined within the current document 
C.1 General 

This subclause describes the media feature tag definitions that are appHcable for the 3GPP IM CN Subsystem for the 
realisation of the MSG server assisted mid-call feature. 



C.2 Definition of media feature tag g.3gpp. mid-call 

Media feature-tag name: g.3gpp. mid-call 

ASN.l Identifier: 1.3.6.1.8.2.x 

Editor's note: The ASN. 1 Identifier will need to be updated once the lANA registration is completed. 

Summary of the media feature indicated by this tag: This feature-tag when used in a SIP request or a SIP response 
indicates that the function sending the SIP message supports the MSG server assisted mid-call feature. 

Values appropriate for use with this feature-tag: none 

The feature-tag is intended primarily for use in the following applications, protocols, services, or negotiation 
mechanisms: This feature-tag is most useful in a communications application, for describing the capabilities of a device, 
such as a phone or PDA. 

Examples of typical use: Indicating that a mobile phone supports the MSG server assisted mid-call feature 

Related standards or documents: 3GPP TS 24.237: "IP Multimedia Subsystem (IMS) Service Gontinuity; Stage 3" 

Security Gonsiderations: Security considerations for this media feature-tag are discussed in subclause 12.1 of 
IETF RFG 3840 [34]. 
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Annex D (informative): 
XIVIL schemas 

D.1 IVISC Server assisted mid-call feature XML schema 



D.1.1 General 

This subclause defines XML schema and MIME type related to the MSC Server assisted mid-call feature. 



D.1.2 XML schema 

<?xml version="l . 0" encoding= "UTF- 8 " ? > 
<xs : schema 

xmlns :xs="http : //www. w3 . org/2 1/XMLSchema" 
elementFormDef ault= " qualified" 
attributeFormDef ault= " unqualified" > 

<xs:element name="mid-call" type= "Tmid-call " /> 

<xs : complexType name="Tmid-call" > 
<xs : sequence> 

<xs : any namespace= " ##other " processContents= " lax" minOccurs= " " maxOccurs= "unbounded" / > 
</xs : sequence> 

<xs : anyAttribute namespace= " ##any" processContents= " lax" / > 
</xs : complexType> 

</xs : schema> 

D.1 .3 lANA registration template 

Editor"s note: The MIME type "application/vnd.3gpp.mid-call+xml" as defined in this subclause is to be registered 
in the lANA registry for Application Media Types based upon the following template. 

MIME media type name: 

application 

MIME subtype name: 

vnd.3gpp.mid-call+xml 

Required parameters: 

None 

Optional parameters: 

"charset" the parameter has identical semantics to the charset parameter of the "application/xml" media type as 
specified in IETF RFC 3023 [21]. 

Encoding considerations: 

Same as encoding considerations of application/xml as specified in IETF RFC 3023 [21] 
Security considerations: 

Same as general security considerations for application/xml as specified in section 10 of IETF RFC 3023 [21]. In 
addition, this content type provides a format for exchanging information in SIP, so the security considerations from 
IETF RFC 3261 [21] apply. 

Interoperability considerations: 
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Same as interoperability considerations as specified in section 3.1 of IETF RFC 3023 [21]. 
Published specification: 

3GPP TS 24.237 "IP Multimedia Subsystem (IMS) Service Continuity", version 9.1.0, available via 
http://www.3gpp.org/specs/numbering.htm. 

AppUcations which use this media: 

AppUcations support the service continuity as described in the published specification. 

Intended usage: 

COMMON 

Additional information: 

1. Magic number(s): none 

2. File extension(s): none 

3. Macintosh file type code: none 

4. Object Identifiers: none 
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CT#45 


CP-090688 


0043 


1 


Changes to definitions and abbreviations 


8.3.0 


9.0.0 


2009-09 


CT#45 


CP-090688 


0044 


3 


Changes to functional entities 


8.3.0 


9.0.0 


2009-09 


CT#45 


CP-090688 


0045 


1 


Changes to Overview 


8.3.0 


9.0.0 


2009-09 


CT#45 


CP-090688 


0046 


1 


Change of Session Continuity to Access Transfer 


8.3.0 


9.0.0 


2009-09 


CT#45 


CP-090688 


0047 


2 


Call flow for Controller UE releases Collaborative Session 


8.3.0 


9.0.0 


2009-09 


CT#45 


CP-090688 


0049 


3 


State Model for Collaborative Session handling 


8.3.0 


9.0.0 


2009-09 


CT#45 


CP-090688 


0055 


3 


Clarification of SR VCC procedure 


8.3.0 


9.0.0 


2009-09 


CT#45 


CP-090685 


0067 


6 


Call flow for UE initiating an emergency session in IMS using 
SRVCC 


8.3.0 


9.0.0 


2009-09 


CT#45 


CP-090685 


0068 


6 


Call flow for EMC using SRVCC procedure 


8.3.0 


9.0.0 


2009-09 


CT#45 


CP-090688 


0072 


1 


Clarification for the Service Control Signalling Path transfer for 
ICS session continuity during PS-PS transfer 


8.3.0 


9.0.0 


2009-09 


CT#45 


CP-090688 


0089 


2 


Add indication of the capability of supporting mid-call feature 


8.3.0 


9.0.0 


2009-09 


CT#45 


CP-090688 


0094 


2 


MSC Server assisted mid-call feature - SRVCC 


8.3.0 


9.0.0 


2009-09 


CT#45 


CP-090685 


0106 


2 


E-SCC AS actions for IMS Emergency call 


8.3.0 


9.0.0 


2009-09 


CT#45 


CP-090688 


0109 


1 


MSC Server assisted mid-call feature - PS to CS 


8.3.0 


9.0.0 


2009-09 


CT#45 


CP-090688 


0111 


3 


MSC Server assisted mid-call feature - PS to PS 


8.3.0 


9.0.0 


2009-1 2 


CT#46 


CP-090929 


0048 


2 


Call flow for Remote party releases Collaborative Session 


9.0.0 


9.1.0 


2009-1 2 


CT#46 


CP-090929 


0096 


3 


Signalling flow for Controller UE releases media flow on 
controller UE 


9.0.0 


9.1 .0 


2009-1 2 


CT#46 


CP-090929 


0097 


3 


Signalling flow for Controller UE releases media on Controllee 

UE 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0099 


3 


Signalling flow for Controllee UE modify media on itself 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0100 


6 


Signalling flow for Remote party adds new media on controllee 
UE 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0101 


3 


Signalling flow for Remote UE releases media 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0110 


3 


MSC Server assisted mid-call feature - CS to PS - Altl 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0116 


4 


Roles for target UE discovery for Inter-UE Transfer 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0117 


5 


Roles of SCC AS for target UE discovery for Inter-UE Transfer 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0122 


1 


MSC Server assisted mid-call feature - flow updates - Altl 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0124 


1 


MSC Server assisted mid-call feature - capability exchange 


9.0.0 


9.1.0 
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update 






2009-12 


CT#46 


CP-090929 


0125 


1 


MSC Server assisted mid-call feature - PS to CS and SRVCC 

updates - Atll 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0128 


1 


IVISC Server assisted mid-call feature - PS to PS updates 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0131 




sec UE not defined 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090927 


0132 




Renaming of E-SCC AS to EATF 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090927 


0133 


2 


E-SRVCC session origination 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090927 


0134 


2 


E-SRVCC access transfer 


9.0.0 


9.1.0 


2009-1 2 


CT#46 


CP-090929 


0136 


2 


Call flow for transferring a media to a controllee UE 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090928 


0146 


1 


Correction on PS-CS transfer information flow 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0149 


1 


[Vise Server assisted mid-call feature - transaction identifiers 


9.0.0 


9.1 .0 


2009-1 2 


CT#46 


CP-09091 1 


0153 


1 


Enabling session continuity functionality 


9.0.0 


9.1.0 


2009-1 2 


CT#46 


CP-090929 


0155 


2 


SC UE procedures for collaborative session establishment for 

transferring media 


9.0.0 


9.1 .0 


2009-12 


CT#46 


CP-090929 


0156 


2 


SC UE procedures for collaborative session establislnment with 
new media 


9.0.0 


9.1 .0 


2009-12 


CT#46 


CP-090929 


0157 


2 


sec AS procedures for collaborative session establishment for 
transferring media 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-09091 1 


0160 


1 


Address the Editor's Note in A. 3. 2 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090911 


0162 


1 


Address the Editor's Note in A. 8.2 


9.0.0 


9.1.0 


2009-1 2 


CT#46 


CP-090929 


0164 


2 


PS to CS transfer for speech and video session with MSC 
Server asisted mid-call feature 


9.0.0 


9.1 .0 


2009-1 2 


CT#46 


CP-090929 


0170 


2 


lUT Procedures 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0171 


2 


Call flow for adding media to controllee UE 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-091047 


0173 


3 


SC AS procedures for collaborative session establishment with 
new media 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0174 


3 


Procedures for releasing media on controllee UE by controller 

UE 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0175 


3 


Procedure for adding new media by remote party 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0176 


3 


Procedure for releasing media on ontroller UE by controller UE 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0177 


3 


Procedure for modifying media on contrllee UE by itself 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0178 


2 


Signalling flow for Controllee UE releases media 


9.0.0 


9.1.0 
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